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鈥搘ait 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:
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?
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.
This seems like a related issue https://github.com/runatlantis/atlantis/issues/305
@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
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?
Interested here as well. Would be great to see a solution. 馃槄
Same problem here, what would be the current solution?
I couldn't think about anything besides restarting the Atlantis deployment.
+1 We are also having this same problem in our mono repo.
Most helpful comment
Same problem here, what would be the current solution?
I couldn't think about anything besides restarting the Atlantis deployment.