Manual targeted project locks via UI

[JosephLivengood]

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

As an engineer, when there's an active incident or maintenance window affecting infrastructure managed by Terraform, I need a way to prevent anyone from running atlantis plan or atlantis apply on specific projects easier than making pr's.

This is commonly needed when, in an incident, clickops/manual csp cli usage occurs to quickly mitigate an issue while investigations continue. There's no easy way to proactively lock a project with an explanation of why it's blocked, which means during incidents, teams have to rely on Slack messages or verbal communication to tell people "don't touch this right now". In a small org this is sustainable but quickly fails for larger orgs.

Describe the solution you'd like

Add the ability to create manual, targeted project locks via the Atlantis web UI with a freeform note.

• A new "Create Manual Lock" action on the index page that accepts: repository (owner/repo), path, workspace, project name, and a note (such as "Locked for incident 1231 investigation")
• Manual locks occupy the same lock key space as PR-initiated locks ({repo}/{path}/{workspace}/{project})
• When a plan is attempted against a manually locked project, the GitHub comment uses a different template such as:

  Plan Failed: This project is currently locked manually by atlantisui. (or known basic auth user of the ui)

  Note: Locked for incident 1231 investigation

  To continue, the manual lock must be removed via the Atlantis UI. Once the lock is released, comment atlantis plan here to re-plan.

• Manual locks can be released through the existing lock detail page. Releasing a manual lock should not attempt to comment on a PR or delete plan files
• Manual locks distinguishable on the index page (showing "Manual" instead of a PR number, "Manual Lock" in the status column)
• The ProjectLock model gains Note and IsManualLock fields. Since locks are JSON-serialized to BoltDB/Redis, this is backward-compatible with no migration

Describe the drawbacks of your solution

• When DisableRepoLocking is set to true, PR plans bypass lock checks via NoOpLocker. Manual locks can still be created in this configuration, but PR plans won't see them. This is arguably correct since the admin opted out of lock enforcement but could be surprising.
• The web UI has no per-user authentication by default so the lock's "created by" field is either the basic auth username or a default like atlantis-ui. Adding better support for federated auth would make adding additional feature to the ui more adoptable but is ultimately out of scope for this

Describe alternatives you've considered

• Global apply lock only: Atlantis already supports disabling applies globally via the UI. This is too broad because it blocks all projects, not just the affected one, and it doesn't block plan either.
• Using the existing lock mechanism by creating a dummy PR: You could open a throwaway PR that triggers a plan on the target project, creating a lock. This is hacky, requires VCS access, pollutes PR history, and doesn't communicate why the lock exists. In an incident I want to quickly lock without all these added steps. A runbook saying to just go to this url and apply a lock is way simpler.

Open questions

1. If a lock exits on a given project from a PR, should a manual lock fail and point the user to the existing lock or should it automagically unlock with a note added the pr holding the lock? Assuming locks should be respected and so to apply a manual hold any prior lock needs released.
2. Should an API endpoint be exposed for this functionality as well with it's initial release? Assuming yes since it wouldn't hurt to add this.