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

Created on 10 Aug 2018  路  8Comments  路  Source: runatlantis/atlantis

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:

  • 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
bug

Most helpful comment

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

All 8 comments

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

alistar79 picture alistar79  路  5Comments

mcdafydd picture mcdafydd  路  4Comments

sstarcher picture sstarcher  路  4Comments

richstokes picture richstokes  路  3Comments

kipkoan picture kipkoan  路  3Comments