Parallel Plan & Apply fails for different terraform states with the same workspace names

[rlonberg]

When Atlantis sets a lock for a workspace, it locks for all workspaces of that name in the entire repo. If I have 2 terraform states, each with a stg & prod workspace, parallel plans will fail for one of those projects and succeed for the other.

Because of this, if I have 10 different terraform states, each with the same workspace naming conventions, 9 of those states will fail and only 1 will produce successful terraform plans.

Looking at the atlantis Go source code, their locking function doesn't take into account the "project". It sets a lock based on repo name, PR number, and workspace name. It's missing a 4th parameter, project name.

atlantis/server/events/working_dir_locker.go

Line 77 in e899a5d

func (d *DefaultWorkingDirLocker) TryLock(repoFullName string, pullNum int, workspace string) (func(), error) {

This function should include the atlantis.yaml project name as well, i.e.

func (d *DefaultWorkingDirLocker) TryLock(repoFullName string, pullNum int, workspace string, project string) (func(), error) {

[joeybaer]

We also use the same workspace naming conventions across all projects and have hit this issue. As the comments elude to in addition to the above referenced code I think how Atlantis is currently writing these to disks also needs to be updated from repo/pull/workspace to something like repo/pull/project/workspace .

[floyola]

Maybe the project key isn't a good idea since it could be many projects pointing to the same dir and that could lead to terraform locking issues.
I know it's a strange use case.

Wouldn't it be better to use something like repo/pull#/path/workspace ?

[Sebor]

I think this issue is similar as #260

[nickperkins]

This would be such a big help for us. I already use an atlantis project configuration file to limit which projects get planned, but they all share a modules directory. Any change causes 12 plans to run which can take 15 to 20 minutes each time.

[IngussNeilands]

+1 on this one

[KevinSnyderCodes]

This should be fixed by #2131 and #2180

[nickperkins]

Sadly #2180 has been reverted by #2253

[nwsparks]

Why was it reverted? The PR has no description and wasn't linked to any github issues.

[cheethoe]

Why was it reverted? The PR has no description and wasn't linked to any github issues.

Probably because of this issue:
#2239

I do hope we can push forward somehow with this change

[nwsparks]

I do hope we can push forward somehow with this change

Same. This is very badly needed and it would be nice to get it prioritized.

Hopefully they leave the pre-release versions up that include this since the reason for reverting it doesn't affect us at all.