The Wayback Machine - https://web.archive.org/web/20201122192512/https://github.com/runatlantis/atlantis/issues/639
Skip to content

/ atlantis

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

Jump to bottom

Document that custom workflows don't use correct terraform version #639

Open
lkysow opened this issue May 22, 2019 · 12 comments
Open

Document that custom workflows don't use correct terraform version #639

lkysow opened this issue May 22, 2019 · 12 comments
Labels
docs

Comments

@lkysow
Copy link
Member

@lkysow lkysow commented May 22, 2019

If you use terraform in your custom workflow, ex

projects:
- dir: .
  terraform_version: v0.12.0
  workflow: custom

workflows:
  custom:
    plan:
      steps:
      - run: terraform init

Atlantis won't use the version of terraform specified via terraform_version. Instead it is just running sh -c "terraform init" so whatever binary is called terraform will be used. To use the correct version (for now) you need to actually specify the path to where Atlantis downloads it:

- run: /home/atlantis/.atlantis/bin/terraform0.12.0
@lkysow lkysow added the docs label May 22, 2019
@nikovirtala
Copy link
Contributor

@nikovirtala nikovirtala commented Jun 1, 2019

We faced this issue last week when updated to Atlantis v0.8.0, and solved it by executing the custom commands with the project-specific Terraform version like this:

- run: terraform$ATLANTIS_TERRAFORM_VERSION
@maximede
Copy link
Contributor

@maximede maximede commented Jun 4, 2019

@lkysow I think it might be a bit more annoying that having to specify the path where the version you want lives in your workflow.

If the version you request is not downloaded yet, it looks like it won't be available for the custom workflow.

Is there any way to force the download in the custom workflow ?
@maximede
Copy link
Contributor

@maximede maximede commented Jun 4, 2019 •
edited

For the docker image, It also looks like newly downloaded binaries are added in /home/atlantis/.atlantis/bin/ which is not in PATH.
Meaning that depending on if you plan to use a downloaded binary or one available by default with the default docker image, you'd need to have some logic to find where the binary is. @nikovirtala 's solution wouldn't work for binaries downloaded by atlantis
@lkysow
Copy link
Member Author

@lkysow lkysow commented Jun 4, 2019

We should add /home/atlantis/.atlantis/bin/ to the PATH before exec'ing.
@maximede
Copy link
Contributor

@maximede maximede commented Jun 5, 2019

Do you mean in the docker-entrypoint.sh file ? If yes, I'm happy submitting a PR for that.
For the other issue ( the binary not being downloaded ), do you want me to create another bug ?
@lkysow
Copy link
Member Author

@lkysow lkysow commented Jun 6, 2019 •
edited

I was thinking doing it in the actual run_step_runner because we shouldn't assume everyone's using our Docker image.

RE bug, yes that sounds good as another ticket.
@smiller171
Copy link

@smiller171 smiller171 commented Jun 12, 2019

RE bug, yes that sounds good as another ticket.

Was this ticket opened?
@maximede maximede mentioned this issue Jun 12, 2019
Closed
@maximede
Copy link
Contributor

@maximede maximede commented Jun 12, 2019

RE bug, yes that sounds good as another ticket.

Was this ticket opened?

it is now, sorry for the delay
@maximede
Copy link
Contributor

@maximede maximede commented Jun 12, 2019

@lkysow

I've been taking a quick look at the run_step_runner solution you were taking about , the issue I have is that we'd need to have access to the UserConfig.DataDir ( which is where it looks like the binaries are downloaded )

It doesn't look like run_step_runner has an easy access to that.
@lkysow
Copy link
Member Author

@lkysow lkysow commented Jun 13, 2019

My implementation thoughts:

  • Add a method to TerraformClient BinDir() string that returns the bin dir
  • Add a new field to RunStepRunner called TerraformBinDir
  • In server/server.go, where RunStepRunner is constructed, set TerraformBinDir to terraformClient.BinDir()
  • now you can use this in the run step runner
@maximede
Copy link
Contributor

@maximede maximede commented Jun 13, 2019

That makes sense to me. Let me try to take a stab at this
maximede added a commit to uw-it-edm/atlantis that referenced this issue Jul 24, 2019
@maximede
Hack to work around runatlantis/atlantis#639
Unverified
This user has not uploaded their public key yet.
GPG key ID: CCBF01A0EA1793C0 Learn about signing commits
Loading status checks…
b29dfc8
maximede added a commit to uw-it-edm/atlantis that referenced this issue Jul 25, 2019
@maximede
Allow repo to select which workflow to use (#8)
Verified
This commit was created on GitHub.com and signed with a verified signature using GitHub’s key.
GPG key ID: 4AEE18F83AFDEB23 Learn about signing commits
3872178 
* Allow repo to select which workflow to use

* Hack to work around runatlantis/atlantis#639
@lkysow lkysow mentioned this issue Jan 23, 2020
Closed
@krzysztof-magosa
Copy link

@krzysztof-magosa krzysztof-magosa commented Sep 8, 2020 •
edited

Seems that projects listed in repository atlantis.yaml do not respect Terraform version stated in versions.tf.
Is that expected behaviour? For a time being I had to set TF version explicitly in atlantis.yaml to bypass that problem.

I use custom workflow, but without custom commands for plan/apply.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs
5 participants
@lkysow @maximede @smiller171 @krzysztof-magosa @nikovirtala
You can’t perform that action at this time.