Bug: GH Action runner's built-in terraform binary over-rides the one installed by tenv

[rdhar]

Description

Following on from #93, it'd appear that VMs with built-in terraform binary—such as GH Action runner—overrides the tenv ... use selection.

Replication

1. View the workflow logs after running the following GH Action step.

   jobs:
     tf:
       runs-on: ubuntu-latest
       steps:
         - run: |
             LATEST_TENV=$(curl --silent https://api.github.com/repos/tofuutils/tenv/releases/latest | jq -r .tag_name)
             curl -O -L "https://github.com/tofuutils/tenv/releases/latest/download/tenv_${LATEST_TENV}_amd64.deb"
             sudo dpkg -i "tenv_${LATEST_TENV}_amd64.deb"
             tenv terraform use 1.6.1
             terraform --version

2. Alternatively, a working demo of this workflow is available here.

Expected behavior

The output of terraform --version should match that of used/installed by tenv.

$ tenv terraform use 1.6.1
$ terraform --version
...
Installation of Terraform 1.6.1 successful
Written 1.6.1 in /home/runner/.tenv/Terraform/version
Terraform v1.6.1
on linux_amd64

Actual behavior

The output of terraform --version reflects the built-in/pre-installed version of terraform, ignoring tenv altogether.

Installation of Terraform 1.6.1 successful
Written 1.6.1 in /home/runner/.tenv/Terraform/version
Terraform v1.7.5
on linux_amd64

Screenshots

Link to existing workflow log which demonstrates the output of the above replication steps.

Environment (please complete the following information):

Sourced from actions/runner-images:

• OS Version: 22.04.4 LTS
• Kernel Version: 6.5.0-1016-azure
• Image Version: 20240324.2.0
• Systemd version: 249.11-0ubuntu3.12

Additional context

Cannot emphasise how appreciative I am of your efforts towards lowering the barrier-to-entry for O/TF, especially in CI contexts such as this. Thank you for your time!

[dvaumoron]

That's probably a path resolution order problem, as you suggest elsewhere, I will look at setup-terraform (else i will dig in GA doc) to find what could be done on tenv side.

[dvaumoron]

The last Open Source version of Terraform is 1.5.7, you can call tenv terraform constraint "<= 1.5.7" to enforce the use of version prior to the license change (however, a request for a specific version will still get it even if it doesn't match the constraint)

[dvaumoron]

https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#adding-a-system-path

[dvaumoron]

There is two thing depending on the goal :

• In order to be able to call the tenv terraform proxy within the same step, an export PATH= to change the resolution order and ensure the use of the tenv proxy
• In order to be able to call the tenv terraform proxy in following steps, the previous link should work.

That mean you need to locate tenv, a which tenv will help, however you need to cut at the last "/".

[rdhar]

Ah, I'm totally fine with being able to call tenv's terraform proxy in subsequent steps, as that's the norm with other setup- GH Actions anyway.

In that case, since adding a system path PREpends it to the system PATH variable, it is possible for it to be implemented in tenv?

Perhaps checking for the presence of the earlier $GITHUB_ACTIONS env var boolean in order to propagate the terraform proxy path in $GITHUB_PATH, just to match the tofu proxy user experience in a CI context (which already happens have its own pre-existing terraform).

[dvaumoron]

I will add a tenv update-path command to do that.

[rdhar]

No way, can't wait to give this a whirl upon release!

[dvaumoron]

1.7.0 is out

[rdhar]

That's fantastic, @dvaumoron, thank you! Should I enable some other flag/input to tenv within GH Action context?

Asking as I ran the test workflow and the logs revealed the in-built Terraform still being favoured over tenv proxy, even when the --version is queried in a subsequent step using the latest 1.7.0 version of tenv.

[dvaumoron]

Have you followed the example export PATH=$(tenv update-path) ?

[rdhar]

I haven't added that line yet as I thought that's being carried out automatically when GITHUB_ACTIONS is true, as per:

Used by tenv update-path when GITHUB_ACTIONS is set to true, path to a file to write tenv directory location.

Perhaps I've misunderstood something, or the echo "{path}" >> $GITHUB_PATH isn't occurring as expected when GITHUB_ACTIONS is true?

[dvaumoron]

tenv <tool> use does not write in $GITHUB_PATH, only tenv update-path does it.

[rdhar]

Ah, I get you now; the following now installs and adds the selected proxy to GITHUB_PATH automatically when GITHUB_ACTIONS is true.

tenv terraform use 1.6.1
tenv update-path

And I can confirm this works (!) as both Tofu and Terraform outputs are reported identically on this PR workflow. 🙌

One slight oddity is that the original/raw TF output is no longer shown within the workflow logs itself. This would be desirable have since:

• the end-user might not want to output the result of TF commands within a PR comment, and view the workflow logs directly.
• the TF plan output may exceed the 65536 characters limit of a PR comment, so the only way to view the entire plan is via the workflow logs directly.

Would it be possible to enable both GITHUB_OUTPUT as well as the regular workflow output logs for TF commands simultaneously, as per setup-opentofu/terraform GH Actions?

[dvaumoron]

Writing both could be done, could you open a new issue for this change ?