Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Process for a repo admin to ignore checks and "force" a merge on an MR #57

Open
MeltyBot opened this issue Feb 28, 2022 · 1 comment
Open

Comments

@MeltyBot
Copy link

Migrated from GitLab: https://gitlab.com/meltano/handbook/-/issues/63

Originally created by @aaronsteers on 2022-02-28 19:14:01


We've moved from a Manager approval model from MRs to a SME/Senior approval model, where we have a more decentralized CODEOWNERS approach and even code owners will require an approval from someone besides themselves.

We also require Pipelines to complete before MRs can be merged.

With this in place, we should talk about the process of force push or force merge - if we want this option and what Gitlab might be able to support.

Does Gitlab support an option to ignore conditions for certain Maintainers/Owners?

Is there are way to set a "Force override" checkbox (or similar) which would allow us in special circumstances to force the merge an unapproved MR or an MR with a failed pipeline? If not an explicit checkmark, then it would be nice if at least there was a warning displayed that you are using your Admin permissions to override the default checks.

Even better if this can also be alerted on as a notification in Slack for audit purposes.

Cc @DouweM, @tayloramurphy, @afolson as folks who might know the answer here.

Alternatives

Currently the process would have to be something like this, performed by a team member with Maintainer permissions:

  1. Go into the project settings and disable checks.
  2. Merge the MR with the checks disabled.
  3. Return to project settings and re-enable checks.

Appropriate use cases for Force Merges

The two cases where this would be most likely are:

  1. Responding to an urgent issue at a time when others are logged off.
    • For example, a release manager in Pacific time or UK time might not have another approver online and would otherwise be blocked on the merge until someone else logs on.
  2. Merging a contributor's MR on a fork that may not have the latest CI tests, or is having other false-positive lint errors or test failures.

Option to Keep As-Is

We can also just decide to keep things as-is, without any change. The downside is that we may be blocked from resolving certain types of issues, and our mitigations generally would involve an administrator disabling/reenabling checks, as described above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant