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

feat: add lock_all_projects_before_exec #4756

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

tufitko
Copy link
Contributor

@tufitko tufitko commented Jul 16, 2024

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

@tufitko tufitko requested review from a team as code owners July 16, 2024 10:23
@tufitko tufitko requested review from chenrui333, lukemassa and nitrocode and removed request for a team July 16, 2024 10:23
@github-actions github-actions bot added docs Documentation go Pull requests that update Go code labels Jul 16, 2024
@tufitko tufitko marked this pull request as draft July 16, 2024 10:23
@tufitko tufitko force-pushed the lock-projects-at-once-before-command branch from 0dbb40a to 774bdfe Compare July 16, 2024 10:53
@jamengual
Copy link
Contributor

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 jamengual added waiting-on-response Waiting for a response from the user feature New functionality/enhancement labels Jul 16, 2024
@tufitko tufitko force-pushed the lock-projects-at-once-before-command branch from 774bdfe to 9ddd2ac Compare July 18, 2024 10:43
@tufitko
Copy link
Contributor Author

tufitko commented Jul 30, 2024

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
Copy link
Contributor

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
Copy link
Contributor Author

tufitko commented Jul 30, 2024

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
Copy link
Contributor

jamengual commented Jul 30, 2024 via email

@tufitko
Copy link
Contributor Author

tufitko commented Jul 31, 2024

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.

Copy link

github-actions bot commented Sep 8, 2024

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 github-actions bot added the Stale label Sep 8, 2024
@jamengual jamengual removed the Stale label Sep 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs Documentation feature New functionality/enhancement go Pull requests that update Go code waiting-on-response Waiting for a response from the user
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants