Pushing to pull requests results in unrendered HTML on Gitlab forges

[Thaodan]

When pushing a new commit to a repository there is a new message about the new commit eg in my latest case:

Thaodan 2 hours ago
added 1 commit

<ul><li>f3846f73 - [sb2] Refactor path handling. Contributes to
JB#51819</li></ul>

This that intended or a bug?
My forge version is: 20201201.1713

[tarsius]

When pushing a new commit to a repository there is a new message about the new commit eg in my latest case:

Either I completely misunderstand what you are talking about or this has nothing to do with Forge. Forge has no say in what Gitlab.com does in response to you effectively running git pull .... If this is actually what you are talking about, then explain why you think Forge has anything to do with it.

[Thaodan]

I meant something like that:

[Thaodan]

[tarsius]

That's certainly unexpected and I've never seen it before. Does that happen just with the gitlab instance we talked about before or also on gitlab.com?

[Thaodan]

Yes same problem see my test PR on one of my projects: https://gitlab.com/Thaodan/aur_helpers/-/merge_requests/1

[tarsius]

Actually I just remembered that this is a feature. I didn't remember before because I don't really use Forge with Gitlab. This was "implemented" in b019dfa.

[tarsius]

The <ul><li> part is new, I believe. Or maybe adding a commit did not result in the creation of what the Gitlab API calls a "note".

In any case this is rather noisy and we should probably filter out some of that text. But I am not thrilled about the prospect of having to use some heuristic again to guess the type of a "note" (see the comment removed by the mentioned commit). So I probably won't tackle this any time soon.

[tarsius]

Classifying as a "upstream bug" because they really should have a type field on the very generic "note" object type.

[Thaodan]

The `<ul><li>` part is new, I believe. Or maybe adding a commit did not result in the creation of what the Gitlab API calls a "note". In any case this is rather noisy and we should probably filter out some of that text. But I am not thrilled about the prospect of having to use some heuristic again to guess the type of a "note" (see the comment removed by the mentioned commit). So I probably won't tackle this any time soon.

I don't think filtering those out make sense as they come into context when something changes e.g. a comment reacting to line of code that is no longer present.

[tarsius]

I agree, these "notes" are useful, but what would be even better is if we could easily tell them apart from comments that were written by human beings. We could then provide different functionality depending on the type of the "note" at point. For example, we could disallow editing "status updates". It is currently possible to attempt to do so; of course it eventually leads to an error, but unfortunately not upfront.

[Thaodan]

Reported the problem upstream:
https://gitlab.com/gitlab-org/gitlab/-/issues/292422

[Thaodan]

Feel free to ad more if I had missed something.

[tarsius]

So far they have talked about who's responsibility it is to look into this. 🙄