Approval Policy and "self-approver" issues

[Marc Zampetti]

We have enabled Control Freak and PR-Booster in order to apply controls to our long-lived repos. One of the issues that has come up is that we occasionally get into a state where a PR cannot be approved because all of the approvers also show up in the commit history. This most often happens when merging a feature branch into a release branch, and the approver has a commit that was introduced into the feature branch due to the branch being created from an earlier commit.

Some of the source of this issue is due to the fact that often one of the approvers will perform the merge, which results in a merge commit in the history. Having the PR creator do the merge cuts down on this, but not eliminate it.

In the case where there is a commit from one of the approvers, what is the best strategy to deal with this case?

‌

[Julius Davies [bit-booster.com]]

‌

Are there sync-merges on the feature branch? (e.g., merges that don’t introduce any new changes, they just keep feature in sync with release).

And was the feature branch quite long-lived?

I wonder if ignoring clean “sync merges” might help a bit here (not counting those towards self-approval). Of course “dirty” sync merges (where a conflict resolution was required) should probably count as self-approval, since in that case the conflict resolution itself required some coding.

What is your branching strategy?

[Marc Zampetti]

We are using the default merge strategy in Bitbucket Server (whatever has been there for years). I don’t recall the exact name. Yes, the feature branch was often long-lived. Or in some cases, there merges in to “sync” from the target branch once in awhile.

The issue is that we are a small team. So often, the same group of people that are doing the PR review will also be making changes on the long-lived branch, which I think would result in the “sync merges” that you are referring to.

So we are just looking for options or best practices to manage this.

[Julius Davies [bit-booster.com]]

‌

I think I can definitely remove clean sync-merges from the calculation of “who is considered a self-approval”. It’s a lot of work, but kinda fun.

Another idea I’ve been toying with: implement a temporary “Control Freak Rules Don’t Apply To Admin X For 5 Minutes” button. That way a user (with admin) could work around this problem in a structured way, including a line in the audit-trail (“Admin X Applied 5-Minute Temporary Override - Reason = Z”).

‌

‌

[Marc Zampetti]

Both of those sounds interesting. We would appreciate and use both.