This message was deleted.
# atlantis-community
s
This message was deleted.
g
It’s been working without issues for me. Can you increase the log level and share the related lines?
b
I unfortunately can't change the log level now and do a dump of the logs
But what I see:
"parsed comment as command="unlock" "Running comment command 'unlock' :"Unlocking all locks" "Deleting plan: "msg":"Failed to delete plan msg":"failed to delete locks by pull remove "failed to delete locks by pull remove /home/atlantis/.atlantis/repos/xxxxxxxxx/15/default/default.tfplan: no such file or directory"
Even though planning, applying, and unlocking on this PR goes fine without any issues
Nothing seems to go wrong, it happens on all the repositories when commenting
atlantis unlock
but the plan is actually deleted fine and the unlock works fine
So the comment is a bit misleading
g
Maybe next time you could check if file does exists before sending the command.
b
I would doubt it exists, as it's looking for a 'default/default.tfplan'
There should be multiple plans under that path as we have multiple projects going off in parallel in every PR
I'm 100% sure we don't store default.tfplan's
Judging by the logs:
successfully ran "/home/atlantis/.atlantis/bin/terraform1.5.0 plan -input=false -refresh -out \"/home/atlantis/.atlantis/repos/xxxxxxx-google-cloud/gcp-tf-xxxxx/15/default/xxxxxxxx-prod-default.tfplan\"
each plan is prefixed with an environment and some identifier
g
you mentioned v0.26, did this started happening after an update?
also can you share your workflows config?
I’m thinking if this is the issue (here):
b
It worked fine on v0.25.0, only since our update to v0.26.0 it started doing this
We've never specified the
-out
before
Pretty sure that the -out file is done by using the project name
Copy code
version: 3
automerge: true
abort_on_execution_order_fail: true
parallel_plan: true
parallel_apply: true

projects:
  - name: gcp-tf-xxxxx-dev
    dir: .
    workflow: gcp-tf-xxxxx-dev
    autoplan:
      enabled: true
    terraform_version: 1.5.0
    execution_order_group: 1

  - name: gcp-tf-xxxxx-test
    dir: .
    workflow: gcp-tf-xxxxx-test
    autoplan:
      enabled: true
    terraform_version: 1.5.0
    execution_order_group: 2

  - name: gcp-tf-xxxxx-acc
    dir: .
    workflow: gcp-tf-xxxxx-acc
    autoplan:
      enabled: true
    terraform_version: 1.5.0
    execution_order_group: 3

  - name: gcp-tf-xxxxx-prod
    dir: .
    workflow: gcp-tf-xxxxx-prod
    autoplan:
      enabled: true
    terraform_version: 1.5.0
    execution_order_group: 4
And the actual workflow:
Not going to share all of them, as they are the same
But:
Copy code
gcp-tf-xxxxx-dev:
    plan:
      steps:
        - env:
            name: GOOGLE_IMPERSONATE_SERVICE_ACCOUNT
            value: <mailto:xxxxx@xxxxx.com|xxxxx@xxxxx.com>
        - run: rm -rf .terraform
        - init:
            extra_args:
              [
                "-lock=false",
                "-backend-config=env/dev/vars/backend-config.tfvars",
              ]
        - plan:
            extra_args: ["-lock=false", "-var-file=env/dev/vars/vars.tfvars"]
g
I found the bug
b
😮 !
notice
Copy code
// The locks controller currently has no implementation of Atlantis project names, so this is hardcoded to an empty string.
	projectName := ""
and then calls
Copy code
removeErr := l.WorkingDir.DeletePlan(lock.Pull.BaseRepo, lock.Pull, lock.Workspace, lock.Project.Path, projectName)
DeletePlan
calls
GetPlanFilename
to get the plan filename (here)
Copy code
// GetPlanFilename returns the filename (not the path) of the generated tf plan
// given a workspace and project name.
func GetPlanFilename(workspace string, projName string) string {
	if projName == "" {
		return fmt.Sprintf("%s.tfplan", workspace)
	}
	projName = strings.Replace(projName, "/", planfileSlashReplace, -1)
	return fmt.Sprintf("%s-%s.tfplan", projName, workspace)
}
but since 0.26, starting on the PR above, the
projName
is empty, so the filename will always be
%s.tfplan
, but in your case it should’ve been
%s-%s.tfplan
like you show on you plan command
👍 1
Can you file this bug pls? Feel free to use all the findings in here
b
Will do
Thanks for diving into it Gabriel
Interestingly enough, it still discards the plan just fine
g
Happy to help 🙂 I’m trying to get increase my knowledge of atlantis, so troubleshooting these things helps 😄
my best guess understanding is that the unlock step
l.Locker.Unlock(id)
, that runs before
deletePlan
still succeeds and the plan file is left behind. Eventually if you plan, the old plan file gets overridden. Could you confirm that with a test?
o
just wanted to let you know that you're not alone @Bruno Schaatsbergen
👍 1
a
We’re seeing the issue too but didn’t get a chance to investigate yet. We see locks are released but see an error in the logs with “Failed to delete PR locks” and comment back on the PR.
👍 1
b
I'll take a stab at making a PR to fix it
💯 2
r