Allow more granular settings for events that trigger un-approval
Issue #11
new
Issue #8 / plugin version 2.0.4 modified the behavior of the plug-in such that an auto-unapproval happened for both new commits AND changing of target branch. Is it possible to make this a more granular setting, so user can choose one, the other, or both? We would like to un-approve on new commits, but NOT on target branch change.
Comments (9)
-
Account Deactivated
-
reporter
Bit of a convoluted deployment process that has grown up around us. When a dev opens a PR, the target is master. When a group of individual PRs have cleared peer review and QA, we create a new release candidate branch from master. The approved PRs are then merged to the release candidate (which is where the target change comes in). The RC goes through a series of automated regression tests, and if passes is staged for deploy to production at a time that suits the various business needs.
The fact that the target change revokes approvals is a minor annoyance. The QA dept has approval perms, and can just re-approve and do the desired merge. But, of course, it generates email noise. Which, I suspect, will eventually lead devs/QA to either filter those emails or turn off alerts. A development which would likely slow overall velocity.
Internally, I've advocated for downgrading to the previous plug-in version. Can you confirm the only change in this latest version is the un-approval on target change?
However, even if we downgrade now, there may be a feature in a later version we want, so I thought it prudent to submit the request.
-
Account Deactivated
Thanks Brian, that makes sense. I can confirm that reverting to 2.0.2 will only change the behaviour as you expect, but your point is valid about future updates.
-
Account Deactivated
@ENDelt260 Been quite a while since you raised this, but I wanted check something. In newer versions of the add-on, if the target branch changes but the new target is referencing the same commit as the previous target, approvals are no longer withdrawn.
Based on the workflow you described above, it seems like the new "release candidate branch" would have the same commit as master (given it was just created from master). That implies a workflow where you create the new release candidate branch and then retarget the relevant pull request(s) should no longer result in approvals being withdrawn.
Do you still use this add-on? Is the current behavior still problematic for you?
-
reporter
We fixed our workflow. :) We no longer, as a matter of course, redirect our PRs to point to a different target after approvals have come in.
So, I guess in answer to your question, no this isn't a problem for me anymore. I can close the ticket if that's appropriate. I don't want to assume that no one else cares, but evidence seems to suggest that may be true.
-
Account Deactivated
Hi there, I would like to chime in here and say that multiple team in our company would very much like this change to be implemented for our workflow.
-
Same in my company. Having our PRs automatically unapproved just because the target branch changes is a major annoyance on a frequent and regular basis. Please make this configurable so that we can turn off auto-unapprove if the target branch changed.
-
Ok, I found a satisfactory workaround to this problem. In our Company, we are using an Add-On called “Workzone” with the option to activate or deactiate the following features, both on a project level as well as on a repository level:
- Unapprove Pull Requests on Source Change
- Unapprove Pull Requests on Target Change
-
This would be very desirable for my company. Even if the commit doesn’t change, certain repositories we maintain need their approvals revoked, as the target branch is sensitive. Please consider this new feature.
- Log in to comment
Hi Brian, this is something that one of the devs may look into in an upcoming innovation week (20% time) - no guarantees though. To help me understand the need, could you tell me a bit more about why you'd like this distinction available?