Atlantis command to disable (or enable?) auto-merge persistently for a particular PR

[dupuy26]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request. Searching for pre-existing feature requests helps us consolidate datapoints for identical requirements into a single place, thank you!
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.
• If you are interested in working on this issue or have submitted a pull request, please leave a comment.

---

• [ ] I'd be willing to implement this feature (contributing guide)

Describe the user story

Often a particular PR will be used for an incremental development or deployment, with multiple rounds of atlantis apply, and it gets a little tiresome to have to remember to add --auto-merge-disabled. Of course, often the PR isn't mergeable (most often because not all projects have been applied), but if you don't disable auto-merge every time, you will eventually be surprised to find out that it was mergeable, and by then it's too late – you can't unmerge a PR.

As a developer, I would like to have a command that I can use to change the auto-merge default for that specific PR, so that I don't have to remember to add --auto-merge-disabled on every atlantis apply.

Describe the solution you'd like

1. At the very least, I want to have a new Atlantis command, atlantis disable-auto-merge (or something similar) that would disable auto-merge for a PR where it is given. Ideally, this would persist for the lifetime of the PR, but it might be OK if it just persisted for as long as any project lock was held. Like any other Atlantis command, the ability to perform this command could be restricted to certain VCS teams in the Atlantis configuration.

2. It would also be nice to have some indication of the auto-merge state (when not in the default state) in the PR. This would depend on the VCS in use, but could be implemented for all Git hosting services except Bitbucket using a label. If that implementation approach is chosen, creation (and perhaps deletion) of the label outside of Atlantis would ideally have the same effect as the Atlantis command, to avoid the possibility that the label is out of sync with the actual state of auto-merge (however, doing that may render team restrictions on the command ineffective)

3. Although (from point 1 above) it would be possible to prevent users from disabling auto-merge for a PR though the command permissions mechanism, having an Atlantis flag / environment variable to enable or disable this new Atlantis command universally, regardless of team permissions, would be useful to avoid complications in team permissions structures, especially when Atlantis has merge capabilities that PR authors may not have.

4. Having the ability to undo the disabling of auto-merge would also be a nice-to-have, but not having that would not be an issue in most cases, since it would still be possible to merge the PR manually, unless the user does not have merge capability but Atlantis does.

5. For symmetry and generality it may even be desirable for there to be a command (or option to the command in point 1) that enables auto-merge, even when auto-merge is not enabled. This can raise many potential security concerns, and any such command or option should not be enabled by default.

In summary, in decreasing importance for implementation, one or more of the following:

1. new atlantis command to disable auto-merge (with per-team restriction like any other command)
2. indication of auto-merge state in PR (VCS dependent, probably using labels, except Bitbucket)
3. ability to enable/disable the new command globally with an Atlantis flag / environment variable
4. new atlantis command/option to undo the disabling of auto-merge
5. new atlantis command/option to enable auto-merge for the current PR if auto-merge is not enabled by default (and this new command/option is explicitly enabled)

Describe the drawbacks of your solution

Implementing his feature may require maintaining additional state specific to the PR, and it could be tricky to do that in a distributed way if you have an HA cluster for Atlantis with multiple live Atlantis instances.

Maintaining the state of the PR across an Atlantis restart would also be a concern here, even without HA.

Using PR labels for the state requires checking PR status before any auto-merge, isn't yet supported for Bitbucket, and would probably make it impossible to enforce team restrictions on the use of this feature. However, it would greatly simplify implementation.

Enabling auto-merge through this interface could be a security concern, if Atlantis has more GitHub permissions than the users who are allowed to comment and permitted by Atlantis to issue the auto-merge (or whatever it is called) command to change the default. However, the ability to disable auto-merge would generally be safe.

Describe alternatives you've considered

Alternative levels and mechanisms of implementation (as discussed above).

Just always remembering to add --auto-merge-disabled every time :-)

[jamengual]

Interesting I'm running into this nuance too and I was thinking to move the auto-merge outside of atlantis and instead use VCSs options to do that.

Adding the state of the disable-auto-merge command will be a lot of work but it is possible.

PRs are welcome.