How to block COMMITs to Approved PRs?

[jh074626]

Occasionally we see branches with Approved Pull Requests updated before they are deployed to Production.  The only way we've seen this happen is when the Merge Masters (my silly term) merge the branches post deployment.

Not necessarily the best way to manage merges to master, but it's what we've got.

What I'd like to know is how the commit can be blocked if there is an Approved PR, or how to send a notification that the commit has occurred?  I'm thinking the latter is the way to go because otherwise, you'd have to have a process to "unblock" the commit so that code could get pushed through.

Any ideas?

[Saxea _Flowie_]

Hi @jh074626

As an alternative to resetting approvals, which can be too drastic in some cases -  just minor stylistic changes or a typo, which would require another 3 re-approvals, depending on your setup; and therefore blocking the merge, some teams prefer to use a workflow where the approvals are marked as 'stale' and the 'Merge Masters' can assess whether to merge or require a re-review of the PR. They can also decide to request just another re-approval or all of them.

Flowie, the addon we provide, adds support for 'stale' approvals (blue dot instead of green):

and the 'Merge Master' can then require the attention of reviewers as necessary to check the PR and re-approve it.

If you have any questions you can reach us on support@flowie.app and we are happy to assist you!

[jh074626]

Saxea, as described by Sean, we have settings in our repo that marks the Approval as "stale" and requiring reapproval.  The problem is knowing it has happened and "blocking" the Jira ticket from CAB approval and/or production deployment.

I'll take a look at Flowie and see if it helps address our specific situation.

[Saxea _Flowie_]

I see, so you need to block the Jira ticket/deployment. 

Flowie 'stale' support is a different feature than the 'reset approval' from Bitbucket. Bitbucket removes the approval while Flowie will mark them as 'stale'. Flagging as 'stale' can be helpful to identify that the problem has happened, but from Bitbucket side only, not Jira. 

Also, we are working on a Jira integration for Flowie, and that could also help with blocking from the Jira side. I'd need to understand better your workflow though. You can shoot an email to support@flowie.app referencing this thread, and I'd be happy to discuss and learn more about it to be able to assist.

[Sean Manwarring _Izymes_]

Hey There

Atlassian have a solution for this with their Premium plan, which it looks like you are already using.

Under the Branch Restrictions tab within the repository settings, if you then click to add a branch restriction, then the “merge settings” tab.

You will want to make sure you have the following ticked (active);

• Minimum number of approvals
• reset approvals when the source branch is modified.
• Prevent merge with unresolved merge checks.

So if someone changes the source branch it automatically unapproves, and then because you require a minimum of 1 or 2 approvals, Bitbucket will block the merge because you are preventing a merge with unresolved merge checks.

Hopefully this solves the issue you are facing 

Sean

// Izymes

[jh074626]

Thank you, Sean.  We already have those settings enabled.  :-)  Those settings have been very important in finding these occurrences.

This issue occurs because the flow we use deploys the code to Production before the merge is done.  So, the Approval is made stale, but the code may be packaged and deployed without that approval.

What I started playing with yesterday was a Jira automation trigger by a Commit.  The idea was that if the PR was Approved, a notification would be sent out saying it needed to be reapproved.

I thought of trying to build something to block the Commit, but that was seemed to be much more complex and would likely require multiple automations or rules, including an "unblock".