Bring back (modified) terraform-github-actions

[mdobosz-isp]

Please read in full before dismissing suggestion based on the title alone.

terraform-github-actions was justifiably obsoleted because it suffered from a few issues:

• it downloaded terraform over and over in every step that used it (thus causing workflows that used multiple different terraform steps to take longer than necessary)
• it was a Docker-based step, which added a slight penalty of requiring the image to be rebuild for every job.

However, the action also offered a number of benefits:

• Proper usage of -detailed-exitcode and other flags, status code propagation, color removal, etc when handling command output
• Built-in creation of GitHub PR comments

It made it really simple to build a PR review/approval workflow that is still challenging to build with setup-terraform alone (e.g. knowing when to set a step to continue-on-error: true, etc.).

Recent developments in the GH Actions world mean that the aforementioned issues can be addressed more elegantly today:

• setup-terraform exists, which can be used to handle the installation of the binary (there are also alternatives out there, starting with the fact that terraform in preinstalled on the github hosted runners, or version management utilities like asdf exist).
• GitHub introduced composite run steps, which makes it easy to implement a reusable step using bash without paying the Docker cost.

My proposal is thus to bring back terraform-github-actions with the following changes:

• Remove the parts responsible for installing a particular version of terraform (including removing the tf_actions_version action argument)
• Convert the action implementation to the "composite" type (instead of Docker-based), leaving the rest of the action input/output interface intact.

This way, we can chose to use the higher-level functionality of terraform-github-actions or invoke terraform directly via run steps.

[heathsnow]

The problem I had with the previous terraform-github-actions is that I have to occasionally execute shell scripts via Terraform and the Docker image for the action didn't have the tools needed for the script to successfully execute. Essentially it meant I couldn't use the action at all for some workflows.

The new setup-terraform however means I can have a previous step that installs my tools onto the agent prior to executing my plan/apply and so my scripts now pass when run within Terraform.

[mdobosz-isp]

The problem I had with the previous terraform-github-actions is that I have to occasionally execute shell scripts via Terraform and the Docker image for the action didn't have the tools needed for the script to successfully execute. Essentially it meant I couldn't use the action at all for some workflows.

The new setup-terraform however means I can have a previous step that installs my tools onto the agent prior to executing my plan/apply and so my scripts now pass when run within Terraform.

@heathsnow What I am proposing would not use Docker-based steps. Instead, they would be composite steps, which execute directly on the runner, thus having access to whatever else you put on there.

[heathsnow]

Ah, I was unaware of the composite run step concept. Thanks!

[sudomateo]

Thank you for writing this up! I was also unaware of composite run steps. I wish this was available when we were in the process of rewriting this action since it seems like a good fit for a CLI tool like Terraform. The Docker action proved to add unnecessary complexity (especially when Terraform already has official Docker images that can easily be used in a GitHub Actions workflow). The alternative for GitHub Actions is a native JavaScript action and JavaScript isn't necessarily the best choice for a CLI tool.

I'd like to see a proof of concept for what this action would look like using composite run steps. I'm in the process of looking for a new maintainer for this project since I transferred teams at HashiCorp. I've been chatting with Project Management to see what our options look like. Either way, I'm going to keep this issue open since it seems to be a viable alternate implementation.

[abatilo]

@marcind and I implemented the bare minimum of what we needed as composite GitHub Actions here:
https://github.com/iStreamPlanet/github-actions/tree/main/terraform-actions

This does not cover every subcommand that was previously implemented.

I know this is a little confusing too but the company we work for made a policy change about allowing us to use our own GitHub accounts instead of a separate one. So @mdobosz-isp and @abatilo-isp that you might see on commit history are now @marcind and @abatilo.

[MPV]

Another option specifically for installing terraform might be to use tfenv (although I haven't yet found/created a GitHub Action for it).

One particular benefit is that it can detect and use the exact version that you have defined with required_version (in a terraform{ ... } block) in your .tf files.

[marcind]

Another option specifically for installing terraform might be to use tfenv (although I haven't yet found/created a GitHub Action for it).

One particular benefit is that it can detect and use the exact version that you have defined with required_version (in a terraform{ ... } block) in your .tf files.

The request in this issue is to make the functionality of terraform-github-actions orthogonal to how terraform gets installed onto the runner. It would be an assumption/requirement of the new implementation that the Workflow author ensures that terraform is available. This issues is not about solving "how to get terraform onto a runner".

[MPV]

@sudomateo Any news on new ownership of this action?

[sudomateo]

Unfortunately not.

[MPV]

For anyone else coming here, this one by @robburger seems promising at the moment:
https://github.com/marketplace/actions/terraform-pr-commenter

[MPV]

I also raised an issue over at SublimeText/Terraform#51 for discussing improving upon the shared terraform formatting used in GitHub to support better syntax highlighting for diffs.

Would be lovely to see someone from HashiCorp join the effort? ❤️

[pecigonzalo]

Adding my voice here, aside from the overall functionality changes, I think the core thing I would like to see here is a separation of setup/wrap. That way we can use a custom installer, and still benefit from the wrapper.

[sudomateo]

Adding my voice here, aside from the overall functionality changes, I think the core thing I would like to see here is a separation of setup/wrap. That way we can use a custom installer, and still benefit from the wrapper.

This is something I pushed for when this action was first being developed and I was outvoted in favor of a combined action. I no longer maintain this action, but I can echo your concerns to others internally. Appreciate all the feedback here!