Add configuration option to delete notes instead of resolving them #494
Conversation
This will reduce PR decoration clutter where lots of commits are added. It only works for GitLab at the moment.
|
I've done something similar in a fork of this project (forked due to the lack of time to make it pr-ready). My changes work differently in some points:
|
|
@felixoi I've looked at "post as first comment" a while back, but that requires elevated privileges according to the docs so I abandoned it. Your second point is a good idea, since that would reduce the number of emails GitLab sends out. Unfortunately I've spent already too much time on this, so I'm going to run locally with what's in this PR. |
|
@teake By "first comment" I though about just posting it before the issue comments, not manipulating the created_at date. Most of the time it will be the first comment in a merge request then (cannot be guaranteed tho). I'm also time limited right now, this one is a good start tho. If it would get merged, I could make a new pull request with some more options/changes to the behavior. |
|
Similar to my comments on #487: I don't really want to have the plugin providing non-standard configuration options, and definitely don't want any options that are misleading to users. The plugin moved away from deleting comments due to it leaving orphaned discussions and system notes in Gitlab so didn't actually reduce the noise in the UI and reduced the overall UX. I'd be ok with the summary comments being deleted if there are no child comments on them, but am not convinced deleting annotations is the right thing to do. |
|
@mc1arke Is the standard configuration that it just posts the summary again and again or is it just editing the first post? |
|
@felixoi It posts a new summary comment on each run, and resolves any existing summary comment discussions |
Could you elaborate a bit on why you find this misleading? To be frank, I don't see it. My main beef with resolved summary comments is that you cannot collapse or hide them in the GitLab UI. Any child comments can be hidden, but the parent comment (which is quite big in terms of vertical height!) cannot. So on MRs with lots of commits and SonarQube summary comments, there will be a lot of space taken up with redundant information. So I do really think removing the summary comments reduces clutter. But yeah, orphaned comments are not particularly nice. Alas, will not be able to find any more time to put into this MR, so feel free to close. |
|
As a user of this plugin with GitLab, we have the same issue as @teake with the resolved summary comments. They take up so much space (since they can't be collapsed) and really clutter up the MR activity timeline. We might have 10 of these summaries in the timeline if the build ran 10 times. I like the idea of not removing them if there is a thread attached though. I think it makes sense to never delete the individual issue comments, as those are collapsed when resolved. |
|
As stated before, I've experienced exactly the same as @austen-herbst and @teake. An individual issue comment should never be removed (they're getting collapsed by Gitlab automatically). My solution is still to just update the first summary comment instead of creating a new one every time. Works pretty well. |
This will reduce PR decoration clutter where lots of commits are added. Note that it only works for GitLab.
To reduce merge conflicts, the commit in this PR is done on top of that of #487. Hence this PR contains also the diff of #487. To see the diff of the relevant commit go to 21e3ec4.