Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

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

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

9 comments

Comment

Log in or Sign up to comment
Aron Gombas _Midori_
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
March 19, 2024

@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.

Like # people like this
Wendy G
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
March 19, 2024

@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_
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
March 20, 2024

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
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
March 20, 2024
Like Aron Gombas _Midori_ likes this
Mehboob Wali March 20, 2024

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?

Screenshot from 2024-03-21 11-44-50.png

Wendy G
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
March 24, 2024

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

See the latest changelog for more details.

Like # people like this
Aron Gombas _Midori_
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
March 25, 2024

@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
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
March 26, 2024

@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

Like Aron Gombas _Midori_ likes this
Aron Gombas _Midori_
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
March 27, 2024

@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.)

TAGS
AUG Leaders

Atlassian Community Events