[go: up one dir, main page]

Skip to content

Push-button automatic approved merge from master

Problem to solve

As a developer, for security reasons my organization has a policy to require re-approval on developers actively pushing new commits to an approved merge request (let's call this the "re-approval policy"). However, my organization has no requirement to re-approve an automated (conflict-free) merge from the master branch back to a merge request. So the re-approval policy unnecessarily slows down the common operation of merging back from master.

Indeed I often need to merge from master back into my branch to pick up changes required for my pipeline to pass. So this is not a hypothetical headache; it's very real.

In conclusion, I would like a way to request that master be automatically merged back into my approved merge request without requiring re-approval, even though my repo is configured to require re-approval on (developer-initiated) push.

This feature would save me time, which might be very urgent time resolving downtime or another critical incident, or more ordinary time delivering features and bug fixes. So the impact to organizations like mine may be significant if this feature is implemented.

Intended users

  • Software Developer
  • Platform Engineer
  • Release Manager
  • DevOps Engineer
  • Systems Administrator
  • Software Engineer in Test

User experience goal

The user should be able to use the UI with GitLab to initiate an automatic merge of the master branch back into the user's approved merge request (when the merge is conflict-free) without requiring re-approval of the merge request, even if the repo is generally configured to require re-approval of merge requests on push.

This feature would be opt-in and configured from the repo settings.

Proposal

The user should be able to use the UI with GitLab to initiate an automatic merge of the master branch back into the user's approved merge request (when the merge is conflict-free) without requiring re-approval of the merge request, even if the repo is generally configured to require re-approval of merge requests on push ("Remove all approvals in a merge request when new commits are pushed to its source branch" in the existing GitLab UI). This would presumably look like a button or other action taken directly from the merge request, probably near other actions and buttons like squash changes or merge.

This feature would be opt-in and configured from the repo settings. Probably right next to the place where re-approval on push ("Remove all approvals in a merge request when new commits are pushed to its source branch") is configured today.

Further details

This feature would save me time, which might be very urgent time resolving downtime or another critical incident, or more ordinary time delivering features and bug fixes. So the impact to organizations like mine may be significant if this feature is implemented.

As a secondary benefit, even repos that do not require re-approval would still benefit from a convenience of automated merge from master.

Permissions and Security

The permissions to perform the push-button automated merge from master would presumably be the same as pushing a commit. So, generally developer role or greater for the repo.

Separately, to enable the automated merge from master from GitLab configuration, that would require the same permission as the existing feature of re-approval on push to a merge request. So, generally the maintainer role or greater for the repo.

Documentation

This feature would presumably be documented in 2 primary places:

  • The push-button automatic approved merge feature itself (core functionality) would be documented alongside the existing documentation about updating a merge request -- things like clearing WIP status, setting squash changes, setting delete branch on merge, etc.
  • The configuration side would be documented alongside the existing documentation for re-approval on push to a merge request.

Availability & Testing

I wouldn't foresee any availability risk.

Test areas impacted would likely be:

  • Unit test changes
  • Integration test changes
  • End-to-end test change

What does success look like, and how can we measure that?

It is easy for a developer to merge automatically from master (when no conflicts) into an approved merge request without requiring re-approval, as long as their repo's maintainer opts into the feature.

As a secondary benefit, even repos that do not require re-approval would still benefit from a convenience of automated merge from master.

What is the type of buyer?

Any organization that develops software.

Is this a cross-stage feature?

Seems likely, yes.

Links / references

Edited by Will Cain