Changes to required scopes for mergeCheck module and new on-reviewer-status-changed trigger

[#1]

Hi all,

We want to share a few important updates on Custom Checks:

• We added a new on-reviewer-status-changed trigger.

• The bitbucket:mergeCheck module now requires the read:pullrequest:bitbucket scope. See the changelog for more details. We understand that changes in scope can be disruptive and we will always do our best to minimise them. However, in this case, this scope is required to allow the check to have access to all required information.

Thanks,
Wendy

[Aron Gombas _Midori_]

@Wendy G I noticed a bug with the new "on-reviewer-status-changed" trigger. Thanks for this new trigger type, this is invaluable.

The bug

When you change the reviewer status by clicking the "Approve", "Unapprove", etc. buttons, the check-mark icon left next to the custom check's name sometimes turns into a spinner, sometimes it doesn't.

The check always gets refreshed, I can see that, but because the icon doesn't start spinning at all. Therefore, the user cannot know if the check was actually re-evaluated. 

It is a visual bug, not a logical one, but will mislead the users.

Request for another trigger

Can you introduce another trigger that re-runs the merge check when the pull request's title, description, other metadata changes? I can see a lot of use cases for that.

[Wendy G]

@Aron Gombas _Midori_ thanks for the feedback. Does this only happen when you approve/unapprove in quick succession? Or it just happens randomly? 

We are in the middle of making a bunch of UI changes including the card on PR page that shows the list of checks, I've raised a ticket on our backlog to investigate further to see if this behaviour is still happening.

On new triggers, could you please raise a new suggestion ticket at https://jira.atlassian.com/projects/BCLOUD/issues/ with Product - Forge as the component. That will help us track & prioritise the various requests related to Bitbucket Forge integration. 

Thanks

Wendy

[Aron Gombas _Midori_]

Hi @Wendy G 

> Does this only happen when you approve/unapprove in quick succession? Or it just happens randomly? 

It happens randomly. (It doesn't matter how fast I click approve/unapprove.)

> We are in the middle of making a bunch of UI changes including the card on PR page that shows the list of checks

I am happy to hear that!

I tried to create an issue for the trigger suggestion, in  https://jira.atlassian.com/projects/BCLOUD but the "Project" drop-down in the "Create Issue" popup does NOT contain the BCLOUD project! (In contrary, it contains BSERV! But in BCLOUD I cannot create an issue, it seems.)

[Wendy G]

@Aron Gombas _Midori_ I've raised https://jira.atlassian.com/browse/BCLOUD-23168 for you.

[Mehboob Wali]

Dear Team . 

I have configured bit-bucket  webhook to triger jenkins pipeline . But I am getting 403 error . 
you can see the below screenshot for better understanding . anyone help me to resolve this issue?

[Wendy G]

Required read:pullrequest:bitbucket scope on bitbucket:mergeCheck module is now enforced at runtime.

See the latest changelog for more details.

[Aron Gombas _Midori_]

@Wendy G Still in the context of Forge-powered merge checks. 

I noticed that it is possible to manually re-run a failed check. But it is not possible to re-run a successful check in the same way... Why?

(I know that I can enforce Bitbucket to re-run a successful check by clicking "Approve", then "Un-approve", but it is a hack, not an intuitive user interaction.)

[Wendy G]

@Aron Gombas _Midori_ are you able to elaborate on your use case for rerunning a successful check?

It is not currently possible to rerun successful checks, but depending on the use cases, we might look into extending the ways a check can be re-triggered in future, so it would help if you could tell us some more details on why you'd need this feature.

In the meantime, if you disable then reenable a check, that will also re-trigger it to run, that is another workaround option. 

Thanks

Wendy

[Aron Gombas _Midori_]

@Wendy G 

are you able to elaborate on your use case for rerunning a successful check?

Sure!

In general, I would say that any "variable" that can affect the merge-ability of the PR and that has no dedicated trigger, will require the user be able to re-run a check even if it was successful.

A few examples that come to my mind:

1. A check to test whether the PR description is not empty.
   1. Example: It passed yesterday, but then someone clears the description today, and the check stays in green - misleading and cannot be re-tested.
      (Yes, I know that there is a feature request for a trigger that runs the check if the PR meta-information changes, but it is not available yet.)
2. A check that connects to Jira to test if the PR title includes a Jira issue key that is in a current sprint and in the status "Shippable".
   1. Example: It passed yesterday, but today someone moved the issue to a future sprint, and the check stays in green - misleading and cannot be re-tested.
3. A check that connects to any external system to test anything externally (a requirement management system containing requirements, security database with vulnerabilities, etc.).
   
   1. Example: It passed yesterday, but then something changes the information in the external system (a new vulnerability was reported), and the check stays in green - misleading and cannot be re-tested.
4. And so on.

 In the meantime, if you disable then reenable a check, that will also re-trigger it to run, that is another workaround option.

Yes, we know about it.

And I can use it, being an admin in our Bitbucket, but regular developers cannot! (They can't administer the repo and the checks.)

[Hillary Chan]

Hi @Aron Gombas _Midori_ , just an update regarding 

> When you change the reviewer status by clicking the "Approve", "Unapprove", etc. buttons, the check-mark icon left next to the custom check's name sometimes turns into a spinner, sometimes it doesn't.

The check results displayed on the PR card are from polling the state of the checks every 5 seconds. The lack of spinner indicates the check was completed within the time to poll. If you would like to confirm the state of your check, you can view `/results` requests in the network tab. Each check will have an `updatedOn` property for when they were last updated.

Cheers,

Hillary