Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Planning a project fails when using new disable autoplan label #3855

Closed
nicolst opened this issue Oct 13, 2023 · 4 comments · Fixed by #3867
Closed

Planning a project fails when using new disable autoplan label #3855

nicolst opened this issue Oct 13, 2023 · 4 comments · Fixed by #3867
Labels
bug Something isn't working

Comments

@nicolst
Copy link

nicolst commented Oct 13, 2023

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request. Searching for pre-existing feature requests helps us consolidate datapoints for identical requirements into a single place, thank you!
  • Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment.

Overview of the Issue

Running atlantis plan -p <some-project> on a PR created with a disable autoplan label (introduced in #3649) will fail because the default workspace does not exist. Running atlantis plan will correctly clone the workspace, and atlantis plan -p works afterward.

I believe the issue is that PRs with the a disable autoplan label are stopped here in runAutoplanCommand. This stops the function chain

autoPlanRunner.Run
p.runAutoPlan
p.prjCmdBuilder.BuildAutoplanCommands
p.buildAllCommandsByCfg
p.WorkingDir.Clone

from running, and therefore the default workspace doesn't get cloned. When running a plan for a specific project, the default workspace is not cloned at any point, it just fails if it doesn't exist. For a general plan it is cloned through this call.

Reproduction Steps

  1. Enable the disable autoplan label feature, e.g. ATLANTIS_DISABLE_AUTOPLAN_LABEL = "no-autoplan"
  2. Open a PR with this label,
  3. Run atlantis plan -p your-project.

Logs

Output

{
  "level": "error",
  "ts": "2023-10-13T10:27:08.199Z",
  "caller": "events/instrumented_project_command_builder.go:75",
  "msg": "Error building plan commands: checking if workspace exists:stat /atlantis/repos/.../default: no such file or directory",
  "json": {},
  "stacktrace": "github.com/runatlantis/atlantis/server/events.(*InstrumentedProjectCommandBuilder).buildAndEmitStats\n\tgithub.com/runatlantis/atlantis/server/events/instrumented_project_command_builder.go:75\ngithub.com/runatlantis/atlantis/server/events.(*InstrumentedProjectCommandBuilder).BuildPlanCommands\n\tgithub.com/runatlantis/atlantis/server/events/instrumented_project_command_builder.go:35\ngithub.com/runatlantis/atlantis/server/events.(*PlanCommandRunner).run\n\tgithub.com/runatlantis/atlantis/server/events/plan_command_runner.go:194\ngithub.com/runatlantis/atlantis/server/events.(*PlanCommandRunner).Run\n\tgithub.com/runatlantis/atlantis/server/events/plan_command_runner.go:292\ngithub.com/runatlantis/atlantis/server/events.(*DefaultCommandRunner).RunCommentCommand\n\tgithub.com/runatlantis/atlantis/server/events/command_runner.go:328"
}

Environment details

  • Atlantis version: v0.26.0
  • Deployment method: Terraform, GKE, Knative

Additional Context

#3649

@nicolst nicolst added the bug Something isn't working label Oct 13, 2023
@jamengual
Copy link
Contributor

@ghaiszaher could you take a look at this?

@ghaiszaher
Copy link
Contributor

I was able to reproduce the issue, the same problem exists when the general disable-autoplan flag is also set to true (e.g. ATLANTIS_DISABLE_AUTOPLAN=true) and regardless of the label (@nicolst could you confirm this?)

@jamengual it's not directly related to the new flag, it also existed before with the disable-autoplan flag. But I will try to understand the issue better and come up with a fix for both cases.

@jamengual
Copy link
Contributor

Thanks a lot @ghaiszaher

@ghaiszaher
Copy link
Contributor

@jamengual @nicolst here is a potential fix: #3867
But please double check that cloning the repo earlier (e.g. before getting the lock) is safe, I haven't checked that part in details.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants