feat: Add option to lock on apply instead of plan

[peikk0]

what

Add option lock_repo_on_apply to lock on apply instead of plan.

why

Use case:

At GitLab we want to use Atlantis in repositories where there can be dozens of Merge Requests being worked on simultaneously, and we want an autoplan on every push, so locking on plan would be very annoying very quickly. Non-locking draftplans would also not be a complete solution, as most often those MRs are not drafts and are just waiting for a review and approval, which can be for many hours. We also have Renovate opening new MRs for automatic updates every day.

Instead, the idea here would be to be able to lock only from the first apply in a MR and until it is fully applied and closed. Plans going stale and needing to be re-planned (even after review and approval) are expected and acceptable in this scenario.

tests

• Deployed my build with lock_repo_on_apply: true set in the server-side repo config
• In a MR, ran atlantis plan, verified in Redis that the lock wasn't set
• Ran atlantis apply -p my_env, verified in Redis that the lock was set
• Ran atlantis apply, verified in Redis that the lock was deleted after the MR was merged.

Also make test.

references

Alternative solution for #1125, #2237

[SimonBiggs]

This is beautiful, thank you. Exceptionally keen for this to land.

[jamengual]

LGTM @peikk0 Thanks for the contribution, lets get another review and then we can merge

[SimonBiggs]

Thanks @jamengual! 🙂

[GenPage]

For the sake of usability, could we possibly combine this with the existing repo_locking that default to true?

My thoughts here are instead of two flags with a boolean that could be confusing from a UX perspective and be conflicting. We change the repo_locking to off|plan|apply.

[peikk0]

I think that makes sense but it should break existing configurations, both server-side and in repos. 🤔

[nikolaik]

I think that makes sense but it should break existing configurations, both server-side and in repos. 🤔

Could use a new variable like repo_locks = off|plan|apply and deprecate the old repo_locking

[jamengual]

we have something similar here #3895 with autoplan: mode

[GenPage]

I think that makes sense, but it should break existing server-side and repos configurations. 🤔

Could use a new variable like repo_locks = off|plan|apply and deprecate the old repo_locking

This could be a good compromise; Thank you, @nikolaik. Can you adjust the PR @ peikk0?

[peikk0]

Sounds good, I will add that.

[peikk0]

Just a note that I'm now working on this after a holiday break, hoping to push the update some time next week. 🤞🏻

[jamengual]

@peikk0 can you look at the linter errors?

[peikk0]

@jamengual I've fixed the linting errors related to this change. The deprecation warning in server/events/vcs/github_client.go:93:17 is unrelated and fixing it is out of scope for this PR so I've just silenced it and added a TODO for it instead.

[jamengual]

@peikk0 last one, could ou fix the conflicts so we can merge it?

[peikk0]

@jamengual conflicts fixed 👍🏻

[jamengual]

thanks for the contribution @peikk0

[peikk0]

@jamengual I've amended my merge commit for some stuff I reverted by mistake in the docs, sorry about that 🙇🏻

[hjkatz]

Are these docs necessarily up to date following this PR? https://www.runatlantis.io/docs/locking

Also, now that locking can occur on_apply and parallel plans are allowed across the same project (for multiple PRs) this means there is no longer a no-op method of locking a project to a specific PR and disallowing applies without first running atlantis apply for the specific PR.

A way to mitigate this would be a manual atlantis lock command that creates the lock for the PR and projects associated.

Do y'all have other recommendations for this type of locking on 1 PR while also using repo_locks: mode: on_apply?

[jamengual]

Those docs are up to date with the default locking, if you use any other option then the docs are per flag in the repo config or server config.

if you do repo_locks: mode: on_apply, then you are going to have to change your workflow to be able to use lock only on apply.

[hjkatz]

there is no longer a no-op method of locking a project to a specific PR and disallowing applies without first running atlantis apply for the specific PR.

@jamengual Do you think there's a no-op apply pattern that would work with atlantis to enable PR locks without applying changes to a root (or really a set of many many roots)?

[jamengual]

if understand correctly you could use draft pr to plan or a regular pr but I don't understand why you will have to apply instead of just closing the pr if the idea is not to apply the code. if that is not what you mean please describe the user flow of what you are trying to do.

…

On Fri, Aug 16, 2024, 7:01 a.m. Harrison Katz ***@***.***> wrote: there is no longer a no-op method of locking a project to a specific PR and disallowing applies *without* first running atlantis apply for the specific PR. @jamengual <https://github.com/jamengual> Do you think there's a no-op apply pattern that would work with atlantis to enable PR locks without applying changes to a root (or really a set of many many roots)? — Reply to this email directly, view it on GitHub <#3879 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQ3ERGFP3GEOWVF64HQ3FDZRYA3FAVCNFSM6AAAAAA6ISPQLCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJTGU3DONZQGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[hjkatz]

So the use-case we have had in the past is via mode: on_plan.

1. Make changes to many many AWS roots (we're about to perform an upgrade)
2. auto-plan, atlantis takes the lock on the PR, now nobody can plan (nor apply) while we're upgrading
3. We make manual TF changes locally and apply via terraform apply (not using atlantis apply), here we are relying on the atlantis PR lock as a communication tactic informing other users that they can't touch TF right now because we are doing things out-of-band
4. We finish the TF changes, now we atlantis plan and confirm there are no changes
5. We atlantis apply (no-op)
6. We merge the PR, atlantis drops the lock, now users can plan/apply on their own PRs

To make a similar process with mode: on_apply we need a way to tell atlantis that other PRs are not allowed to apply any of the roots touched in our PR. Normally this would be coordinated via the atlantis lock (on_plan) on our PR, but since we're using on_apply that atlantis lock no longer exists.

We would ideally still want a way to "claim" the projects via an atlantis lock command, or atlantis apply --no-op or something....

Am I making any sense?

[hjkatz]

@jamengual Any thoughts on this use-case?^

[jamengual]

@jamengual Any thoughts on this use-case?^

is a good use case 😎

[hjkatz]

Great! I've opened a feature request for this: #4877