When a Discussion is marked as resolved or unresolved, it's not possible to get triggered by the Webhook, because it's not seen as an event.
Target audience
Persona: Systems Administrator
Further details
If we need to do specific actions when a discussion is marked as resolved or unresolved, it's not possible currently
Proposal
Add to these buttons :
Mark as resolved / Resolve discussion / Unresolve discussion
the possibility to get triggered on the Settings > Integration > Trigger > Merge Request Events option
What does success look like, and how can we measure that?
When these buttons are pushed :
Mark as resolved / Resolve discussion / Unresolve discussion, it's possible to trigger them on the Merge Request Events.
Mark Fletcherchanged title from {-Trigger events when push button on Mark as resolved/Resolve discussion/Unresolve discussion-} to {+Fire WebHooks for Mark as resolved/Resolve discussion/Unresolve discussion events+}
changed title from {-Trigger events when push button on Mark as resolved/Resolve discussion/Unresolve discussion-} to {+Fire WebHooks for Mark as resolved/Resolve discussion/Unresolve discussion events+}
We are trying to integrate GitLab's merge request status into JIRA issues (label them) using WebHooks. It is easy to detect merge request status changes using merge_request and note events but it is impossible to act upon discussion resolution status. Therefore we cannot detect that the merge request is possible to be merged when discussion is being resolved #195160 (closed). This could be workaround (or maybe correct way?).
We are having the same need; we want to automate settings some labels based on whether there are open discussions on an MR. currently this is not possible as (un)resolving a thread does not trigger a webhook.
@danielgruesso Wanted to ping you to see if this falls within your group. If it helps to chat with the customer, I can schedule a call. Please let me know
This probably makes the most sense in the Comment on a merge request webhook on notes that are resolvable, unless we want to create a whole new event, but it doesn't seem to be as beneficial being completely separate.
We could also expose, more simply, the merge requests discussion state on the MR event, which would indicate whether blocking discussions have been resolved or not (true or false).
Michelle pointed me over here, looks like I didn't see this issue back when i created #214372.
This would really help us out, since we wrote a small service that synchronizes a calculated/consolidated MR status into Jira (indicating whether a MR is good to go, has unresolved discussions, is not mergable etc.) instead of letting the regular Jira integration handle it.
However, marking the last unresolved discussion as resolved and not leaving a comment (which would trigger the Note webhook) is throwing this status off until the next event - if there is one coming at all. For now, I've instructed my fellow developers to leave a comment along with it, and it works organizationally; but I'd much rather have it just-work™.
By the way: for my particular use case, it would be sufficient to trigger one event when the blocking_discussions_resolved flag flips from false to true (or vice versa) rather than triggering one for every resolve/unresolve.
We are a premium customer integrating GitLab with our workflows. We want to trigger automation to merge MRs automatically when all the conditions are met, one of them being that all threads are resolved.
In the same position with integrating with 3rd party software and would love to see this addressed. I'm currently left with a gap when the last thing blocking an MR is a discussion and it gets marked as resolved - the MR is now good to go, but there's no event emitted to trigger other updates on.
If you're accepting input, the option @m_gill outlined to expose the discussion state in an MR event would be very welcome for me.
@mfettig Looking at the linked MRs, it looks like this was contributed and has been deployed to GitLab.com production about 3 weeks ago. I'd expect this will be in the upcoming %14.6 release for self-managed.
AFAIK the MR update event is getting an additional field. Is it possible to detect the flip from the changes object? Having the new field is already a good thing, but being able to detect the change only would be ideal, or else every new MR update after discussions are resolved will be indistinguishable from the first one.
I understand, but what I'm saying is that if you get a webhook with you can't know without some saved state that this was the flip. Every new note event or MR update event will say it is resolved. It's the same as with the MR approval event, but from the number of approvals you can tell if the MR had its approval requirements just satisfied.
Do you actually have to know that? My webhook receivers simply check for whether certain fields are set (or not), and computed a final status for an external site. It only concerns itself with "are there open discussions", "is this mergable" etc. but doesn't really matter if it went from "has open discussions" to "all discussions resolved" (since it might still be unmergable when considering all status flags).
My main complaint before was that there was no event being raised when the dev simply hit the "resolve" button on a discussion (without leaving a comment) and it ended up flipping from "has open discussions" to "all discussions resolved". I made myself clear to my team to not do that because of this limitation (with the workaround of using the comment webhook), but every now and then it still happens (mostly by accident when a push also resolved discussions while the site was not up2date yet). If this is taken care of by the referenced MR, I'm good. (I can read some ruby, but I can't tell if this is actually the case here. I'll see after the update on-premise)
I don't, but it would be better. Currently my integration listens for all comments and check MRs for the all blocking_discussions_resolved flag. If I could listen only to MRs flipping it would save setting up a runner and running a script to query the MR and see if my automation already have run.
In my case it's automating the merge. I guess I can tight the conditions and check if the MR is still opened, as previous events would trigger the merge.
In summary, sorry for the noise, we can close this.
@claudio.pereira1 no worries about the noise! If there's additional work here that would make your workflow easier, I'd encourage you to open a new issue outlining what you're looking for!
By testing this, I seem to find that when you resolve a thread it will fire a webhook, but when you unresolve that thread again, the webhook is not fired again. This does break external workflow tooling.
@lzampier@kerrizor In looking at !67689 (merged) it does seem like the webhook was only done for resolving threads is that correct? Should we open a new issue for unresolve?
I sort of wonder if we need a trigger for threads being unresolved... that's effectively a state change. I don't know if we need it for each thread each time, but some kind of global "there are unresolved threads" and "all threads are resolved".
We've discussed this concept of there are unresolved threads on a thread on 67689 calling it there are unresolved discussions, If I remember, I couldn't find a way to asynchronously check for unresolved threads as most of the checkers, mergeable? and check_mergeability, don't look at discussions.
I'd be happy to add firing the webhook on resolve -> unresolve, but again - is it noisy?
@kerrizor@lzampier Is there a way to do that with some kind of state/condition? Like if >1 discussion unresolved don't send the webhook. That way we're not noisy... but we catch the condition of all threads resolved and now some threads unresolved?
My 2ct: we just care about flipping state (combined with "Discussions must be resolved" as: "can be merged" vs. "cannot be merged") and not necessarily every single toggle (it doesn't matter if we go from 2 threads to 3 because of an unresolve, or from 2 threads to 1 because of a resolve; the end result is still "not all discussions are resolved" and the Merge button is disabled.)
@AlexanderH I'm not sure I understand your question here. What do you mean by event also has the value merge? Are you talking about the object_attributes.action field and the available values in that payload?
Yes, I am talking about the object_attributes.action.. But I guess that it's not a gitlab issue. AFAIKT ATM its a jenkins gitlab integration issue (https://plugins.jenkins.io/gitlab-plugin/), which returns MERGE in the gitlabActionType variable. Need to dig a bit deeper. Guess my ping was too early
Kai Armstrongchanged title from Fire WebHook{-s for Mark as resolved/Resolve discussion/Unresolve discussion events-} to Trigger webhook when all threads are resolved
changed title from Fire WebHook{-s for Mark as resolved/Resolve discussion/Unresolve discussion events-} to Trigger webhook when all threads are resolved