Atlantis comments that workspace is locked on non-tf pull requests

[lkysow]

Reported by a user in the Atlantis Slack.

They have a big monorepo with lots of pull requests. Sometimes non-tf pull requests will see a comment from Atlantis:

the default workspace is currently locked by another command that is running for this pull request–wait until the previous command is complete and try again

It's happening because before Atlantis can figure out if a pull request should be acted on, it clones it and tries to read its atlantis.yaml file. To clone it, it needs to lock the dir where it would clone it. If another pull request event comes in as this is happening, then Atlantis gives an error.

Possible solutions:

• make an api call to find out if there's an atlantis.yaml file. If not, make an api call to find out if there are any .tf files changed. If not, then no need to clone.
• don't send the "workspace is locked" message for pull request updates, only comments.
  • this will be bad if two commits in a row are pushed to a real terraform change since only the first will be planned and there will be no warning that the second was discarded
• queue up "runs" for each pull request

[ajbouh]

There are a number of commands that can operate directly against a bare git repository that allow you interrogate the state of files without needing to check them out.

Would using these commands help avoid the need to lock the workspace?

[lkysow]

I think that would half-solve the problem. But I'd like to tackle this through the queuing up of runs since that's a better long-term solution.

[matkam]

This seems like a related issue #305

[mbamber]

@lkysow - has there been any update on this? We have just started using atlantis and this is happening on a lot of our non TF PRs

[hack2learn]

We would love to see this as well as we use a mono repo.
If we could provide a base path that would be ideal and ignore anything else that does not start with the base_path within such a mono repo. Could maybe be controlled in atlantis.yaml or a server side repo config?

[marsavela]

Interested here as well. Would be great to see a solution. 😅

[Isan-Rivkin]

Same problem here, what would be the current solution?
I couldn't think about anything besides restarting the Atlantis deployment.

[BoraxTheClean]

+1 We are also having this same problem in our mono repo.

[jurgen-weber-deltatre]

this is happening for us when using dependabot.

[jurgen-weber-deltatre]

can the commands just queue instead of erroring? You obviously know something is going on just queue and keep going until its all done.

[povils]

Any updates? it's 3 years already.
Are there any workarounds?

[m00lecule]

bump

[ashleydavies]

For posterity, it seems like the --skip-clone-no-changes flag added in #967 should solve this problem

[BoraxTheClean]

For posterity, it seems like the --skip-clone-no-changes flag added in #967 should solve this problem

This does not resolved the issue for us. We have had this flag enabled the entire time we've been experiencing this bug. I believe this is due to the fact that we use hooks to dynamically create our atlantis.yaml after clone.

[mcrivar]

same issue here, when commit is with changes on two or more catalogs, they just block each other and are not executed.

[pantelis-karamolegkos]

Can anyone elaborate on that

non-tf pull requests

mean?

We are experiencing this issue on normal TF PRs.

Actually we use parallel and create workspaces flags and this can happen on a percentage of say 10 parallel plans that were executed.

We have a large terragrunt monorepo and atlantis.yaml is generated dynamically via terragrunt-atlantis-config but I don't think this is causing the problem.

[jamengual]

I do not think this is the case anymore, is this still an issue with v0.19.8?

[pantelis-karamolegkos]

@jamengual is this supposed to be resolved for versions > 19.8 ?

[jamengual]

yes