Available types of triggers for custom merge checks

[Yannis Argyropoulos __ScriptRunner - The Adaptavist Group__]

Hi!

If I understand correctly, the pre-merge merge checks can only be triggered by these 2 events :

• on-reviewer-status-changed
• on-code-pushed

This would mean that if I create a custom merge check that does something like checking all comments, or checking the pull rerquest title, then my merge check would not re-run after the title was edited, or a new comment is added etc. If I wanted the merge check to run again, I would have to manually click the 'rerun' button (if last run was rejected)

And if the previous merge check had passed, there is no 'rerun' button either, so if as a user, I wanted to re-run it, I'd have to push a change or unapprove/re-approve to force the merge check to re-evaluate

Am I currently missing something, or is there another way to make custom merge checks re-run?

Also are there any plans to add more triggers in the near future, like 'on-pull-request-rescoped', 'on-pull-request-comment-activity' etc?

Regards

[Edmund Munday]

Hi @Yannis Argyropoulos __ScriptRunner - The Adaptavist Group__ & @Aron Gombas [Midori] -  a few points on this:

1. There are currently 3 triggers:
   1. `on-code-pushed`
   2. `on-reviewer-status-changed`
   3. `on-merge`
2. Today, you would use an `on-merge` trigger for most of the use-cases you cited there.
   1. This is basically your "fall-back" trigger which will work for any scenario.
      1. It will run as the user clicks "merge" and enforce any rules you want to validate at that time, failing the merge if they don't pass.
   2. It's effectively designed to be a "catch-all" event. Obviously not perfect as the user doesn't get that feedback until the end of the PR, but does guarantee the state with no opportunity for gaps.
3. We're planning to add more triggers for Custom Merge Checks in the future. It would be great to get your respective "wish lists" and use-cases.
   1. A few items high on the agenda right now are:
      1. A generic "PR Metadata Changed" event that would cover things like the title, description, and other forms of metadata.
      2. PR comments changed.

[Sebastian Hesse]

@Edmund Munday two additions for the "wish list":

1. A manual trigger might be helpful as a fallback for a user (in case the check is already success/green - so far, you can only refresh the check if it failed). However, this gets a lower priority if more and more triggers will be added soon-ish.
2. An endpoint that a Forge app can call to trigger a merge check again. This is really helpful if an app deals with other systems and wants to update the merge check result. In the best case the merge check would be updated "live" on a page but I'm not sure if your current architecture supports this.

[Yannis Argyropoulos __ScriptRunner - The Adaptavist Group__]

Hi Edmund, thank you for your answer, and updating BCLOUD-23168!

You're right, `on-merge` would currently be the best alternative for what I had in mind. And I can imagine, you cannot create a 'pre-merge' trigger, you would need to create a separate trigger for each possible pull-request-related event. If I come up with more events or use cases, I'll share.

But generally speaking, I had the impression that custom merge checks would give a feedback to the user when visiting the pull request page, and before they click the 'merge button', I think most users coming from Bitbucket Server would expect this behaviour

Regards,

Yannis

[Aron Gombas [Midori]]

@Yannis Argyropoulos __ScriptRunner - The Adaptavist Group__ Few weeks ago I asked for roughly the same that you mentioned here. There was a public feature request (a Jira issue) created from my suggestions.

Do you want me to look it up for you?

[Yannis Argyropoulos __ScriptRunner - The Adaptavist Group__]

Thanks Aron, I believe https://jira.atlassian.com/browse/BCLOUD-23168 is the jira you're talking about. I will be watching for it!

What I had in mind was a complete list of all triggers that are possible by using custom merge checks and the bitbucket api, not a specific trigger.

I think the title, description and other metadata do not cover all the possible triggers, for example we'd need more triggers like comment or reply added, changes in reviewers, target branch, etc

[Aron Gombas [Midori]]

Yes, that is the one!

I agree, it could cover the change of other fields, too, or maybe there could be specialized triggers for comments or reviewers.

I encourage you to add this to that issue, or open a separate feature request linked to the existing one.