feat: add lock_all_projects_before_exec

[tufitko]

what

Add new feature lock_all_projects_before_exec.
If this option is enabled, Atlantis will lock each changed project before executing planning/applying on any of the projects.
An example is provided in the docs.

why

Currently, Atlantis acquires locks on a project right before executing the plan on it, one by one. However, one of the following plans may fail if it cannot acquire a lock. This can be very frustrating when planning a lot of projects and encountering lock errors after some time.
Locking all changed projects before running the plan can save a lot of time.

tests

~in progress

[jamengual]

what about using https://www.runatlantis.io/docs/server-side-repo-config.html#repolocks instead of adding this feature? have you try not locking on plan ?

[tufitko]

what about using https://www.runatlantis.io/docs/server-side-repo-config.html#repolocks instead of adding this feature? have you try not locking on plan ?

@jamengual
In that case, we should prohibit parallel applies altogether. Otherwise, one apply can overwrite the changes of another 🤔
and I'm not sure that suitable for us

• we use Terragrunt with a structure where all regions are described in one workspace, and we often apply changes partially by region
• sometimes we lock the pull request and partially apply changes (for testing purposes, for example). With locks on the apply, we won’t be able to do that

[jamengual]

but you already have locks in apply and plan....that the Atlantis default, so having locks only at the apply level will allow you to plan as much as you want and only the last successful plan will be the one that will be applied. (as it is currently )

[tufitko]

Oh, I just realized, locks are not removed during partial apply, right?
We will try using lock on_apply.
My only concern is that after a partial apply, we might need to change something and run the plan again, which would remove the locks (after the plan). A partial plan will not remove the locks, but after applying such a plan, the pull request will automatically merge (it's quite a convenient option).
Please, correct me if I am wrong.

[jamengual]

A partial plan will still work the same way, that does not change.

…

On Tue, Jul 30, 2024 at 12:08 PM Andrei Vydrin ***@***.***> wrote: Oh, I just realized, locks are not removed during partial apply, right? We will try using lock on_apply. My only concern is that after a partial apply, we might need to change something and run the plan again, which would remove the locks (after the plan). A partial plan will not remove the locks, but after applying such a plan, the pull request will automatically merge (it's quite a convenient option). Correct me if I am wrong. — Reply to this email directly, view it on GitHub <#4756 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQ3ERDC3OPYVVESQCLHYYDZO7QEHAVCNFSM6AAAAABK6I7HO6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENJZGAZDKNZWG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[tufitko]

I tried using lock on_apply, and we will definitely use it. However, there is still a problem. If someone partially applied a module, a larger apply might fail halfway through the modules, leaving us in an unpleasant situation where some modules are already deployed and the rest need to be applied.

It seems better to know in advance (before any apply) if a module is locked and unlock it beforehand. Additionally, it would be prudent to lock all modules that will be applied in advance to prevent parallel applies(here, apply of pull request, not project) from affecting the same modules.

[github-actions]

This issue is stale because it has been open for 1 month with no activity. Remove stale label or comment or this will be closed in 1 month.

[github-actions]

This issue is stale because it has been open for 1 month with no activity. Remove stale label or comment or this will be closed in 1 month.