Top Related Projects
Set up your GitHub Actions workflow with a specific version of node.js
Set up your GitHub Actions workflow with a specific version of Python
Set up your GitHub Actions workflow with a specific version of Java
Set up your GitHub Actions workflow with a specific version of Go
Terragrunt is a flexible orchestration tool that allows Infrastructure as Code written in OpenTofu/Terraform to scale.
Quick Overview
The hashicorp/setup-terraform repository is a GitHub Action that sets up Terraform CLI in your GitHub Actions workflow. It allows you to easily install and configure Terraform for use in your CI/CD pipelines, enabling infrastructure as code practices directly within your GitHub workflows.
Pros
- Easy integration with GitHub Actions workflows
- Supports multiple Terraform versions, including the latest releases
- Provides options for wrapper scripts and custom Terraform binary locations
- Includes built-in caching to speed up subsequent runs
Cons
- Limited to GitHub Actions environment, not usable in other CI/CD platforms
- Requires some familiarity with GitHub Actions syntax
- May need additional configuration for complex Terraform setups
- Dependent on GitHub's infrastructure and availability
Getting Started
To use the setup-terraform action in your workflow, add the following step to your job:
steps:
- uses: hashicorp/setup-terraform@v2
with:
terraform_version: 1.0.0
- run: terraform init
- run: terraform plan
This example installs Terraform version 1.0.0 and runs terraform init and terraform plan. You can customize the version or add more Terraform commands as needed.
For more advanced usage, you can specify additional options:
steps:
- uses: hashicorp/setup-terraform@v2
with:
terraform_version: latest
terraform_wrapper: false
- run: terraform --version
This example installs the latest version of Terraform and disables the wrapper script. It then runs terraform --version to verify the installation.
To use Terraform Cloud features, you can add authentication:
steps:
- uses: hashicorp/setup-terraform@v2
- run: |
cat << EOF > $HOME/.terraformrc
credentials "app.terraform.io" {
token = "${{ secrets.TF_API_TOKEN }}"
}
EOF
- run: terraform init
This example sets up Terraform Cloud authentication using a secret stored in your GitHub repository.
Competitor Comparisons
Set up your GitHub Actions workflow with a specific version of node.js
Pros of setup-node
- Supports multiple Node.js versions and package managers (npm, yarn, pnpm)
- Provides caching capabilities for dependencies
- Widely used and well-maintained by the GitHub Actions team
Cons of setup-node
- Limited to Node.js ecosystem
- May require additional setup for specific Node.js tools or frameworks
Code Comparison
setup-node:
- uses: actions/setup-node@v3
with:
node-version: '14'
cache: 'npm'
- run: npm ci
- run: npm test
setup-terraform:
- uses: hashicorp/setup-terraform@v2
with:
terraform_version: '1.0.0'
- run: terraform init
- run: terraform plan
Key Differences
- setup-node focuses on Node.js and its package managers, while setup-terraform is specific to Terraform
- setup-node offers built-in caching, whereas setup-terraform requires separate caching steps
- setup-terraform includes Terraform-specific features like wrapper scripts and version constraints
Both actions are essential for their respective ecosystems, providing easy setup and configuration for GitHub Actions workflows. The choice between them depends on the project's technology stack and requirements.
Set up your GitHub Actions workflow with a specific version of Python
Pros of setup-python
- Supports multiple Python versions and distributions (e.g., PyPy, CPython)
- Allows caching of dependencies for faster workflow execution
- Provides cross-platform compatibility (Windows, macOS, Linux)
Cons of setup-python
- Limited to Python-specific setups, unlike setup-terraform's broader infrastructure focus
- May require additional steps for managing Python packages and virtual environments
Code Comparison
setup-python:
- uses: actions/setup-python@v4
with:
python-version: '3.x'
cache: 'pip'
- run: pip install -r requirements.txt
setup-terraform:
- uses: hashicorp/setup-terraform@v2
with:
terraform_version: 1.0.0
- run: terraform init
Key Differences
- Purpose: setup-python focuses on Python environments, while setup-terraform is tailored for Terraform workflows
- Versioning: setup-python offers more flexible version selection, including major version ranges
- Caching: setup-python includes built-in caching capabilities for dependencies
- Ecosystem: setup-terraform integrates seamlessly with other HashiCorp tools and workflows
Use Cases
setup-python is ideal for:
- Python-based projects and applications
- Data science and machine learning workflows
- Web development with Python frameworks
setup-terraform is better suited for:
- Infrastructure as Code (IaC) projects
- Cloud resource management and provisioning
- DevOps and CI/CD pipelines involving infrastructure changes
Set up your GitHub Actions workflow with a specific version of Java
Pros of setup-java
- Supports multiple Java distributions (AdoptOpenJDK, Zulu, etc.)
- Allows caching of dependencies for faster builds
- Provides options for custom Java package management
Cons of setup-java
- Limited to Java ecosystem setup
- May require additional configuration for complex Java projects
- Less integrated with cloud-specific tools compared to setup-terraform
Code Comparison
setup-java:
- uses: actions/setup-java@v3
with:
java-version: '11'
distribution: 'adopt'
cache: maven
setup-terraform:
- uses: hashicorp/setup-terraform@v2
with:
terraform_version: 1.0.0
cli_config_credentials_token: ${{ secrets.TF_API_TOKEN }}
Key Differences
- Purpose: setup-java focuses on Java development environments, while setup-terraform is specific to Terraform infrastructure-as-code workflows.
- Ecosystem: setup-java caters to Java developers and projects, whereas setup-terraform targets DevOps and infrastructure teams.
- Features: setup-java offers more flexibility in terms of Java distributions and versions, while setup-terraform provides better integration with Terraform-specific features and cloud providers.
- Caching: setup-java includes built-in caching mechanisms for dependencies, which is not a primary focus for setup-terraform.
- Configuration: setup-terraform typically requires less configuration for Terraform projects, while setup-java may need more customization for complex Java environments.
Set up your GitHub Actions workflow with a specific version of Go
Pros of setup-go
- More versatile, can be used for any Go project, not limited to Terraform
- Supports multiple Go versions and architectures
- Actively maintained with frequent updates
Cons of setup-go
- Lacks Terraform-specific features and optimizations
- Requires additional configuration for Terraform-related tasks
- May not provide seamless integration with other Terraform tools
Code Comparison
setup-terraform:
- uses: hashicorp/setup-terraform@v1
with:
terraform_version: 1.0.0
cli_config_credentials_token: ${{ secrets.TF_API_TOKEN }}
setup-go:
- uses: actions/setup-go@v3
with:
go-version: '1.17'
- run: go install github.com/hashicorp/terraform@v1.0.0
Summary
While setup-terraform is specifically designed for Terraform workflows, offering seamless integration and optimized features, setup-go provides a more general-purpose solution for Go projects. setup-go offers greater flexibility in terms of Go versions and architectures but requires additional configuration for Terraform-specific tasks. The choice between the two depends on the project's needs and the level of Terraform-specific functionality required in the workflow.
Terragrunt is a flexible orchestration tool that allows Infrastructure as Code written in OpenTofu/Terraform to scale.
Pros of Terragrunt
- Provides advanced features like remote state management and code reuse
- Supports multi-region and multi-environment deployments
- Offers better modularity and DRY (Don't Repeat Yourself) principles
Cons of Terragrunt
- Steeper learning curve due to additional concepts and syntax
- Requires extra setup and configuration compared to vanilla Terraform
- May introduce complexity for simpler projects
Code Comparison
setup-terraform:
- uses: hashicorp/setup-terraform@v1
with:
terraform_version: 1.0.0
Terragrunt:
terraform {
source = "git::git@github.com:foo/modules.git//app?ref=v0.0.3"
}
include {
path = find_in_parent_folders()
}
The setup-terraform action is primarily used in GitHub Actions workflows to set up Terraform, while Terragrunt is a wrapper around Terraform that provides additional features and capabilities for managing infrastructure as code. setup-terraform is simpler to use for basic Terraform setups, while Terragrunt offers more advanced functionality at the cost of increased complexity.
Convert
designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
setup-terraform
The hashicorp/setup-terraform action is a JavaScript action that sets up Terraform CLI in your GitHub Actions workflow by:
- Downloading a specific version of Terraform CLI and adding it to the
PATH. - Configuring the Terraform CLI configuration file with a HCP Terraform/Terraform Enterprise hostname and API token.
- Installing a wrapper script to wrap subsequent calls of the
terraformbinary and expose its STDOUT, STDERR, and exit code as outputs namedstdout,stderr, andexitcoderespectively. (This can be optionally skipped if subsequent steps in the same job do not need to access the results of Terraform commands.)
After you've used the action, subsequent steps in the same job can run arbitrary Terraform commands using the GitHub Actions run syntax. This allows most Terraform commands to work exactly like they do on your local command line.
Usage
This action can be run on ubuntu-latest, windows-latest, and macos-latest GitHub Actions runners. When running on windows-latest the shell should be set to Bash. When running on self-hosted GitHub Actions runners, NodeJS must be previously installed with the version specified in the action.yml.
The default configuration installs the latest version of Terraform CLI and installs the wrapper script to wrap subsequent calls to the terraform binary:
steps:
- uses: hashicorp/setup-terraform@v3
A specific version of Terraform CLI can be installed:
steps:
- uses: hashicorp/setup-terraform@v3
with:
terraform_version: "1.1.7"
Credentials for HCP Terraform (app.terraform.io) can be configured:
steps:
- uses: hashicorp/setup-terraform@v3
with:
cli_config_credentials_token: ${{ secrets.TF_API_TOKEN }}
Credentials for Terraform Enterprise (TFE) can be configured:
steps:
- uses: hashicorp/setup-terraform@v3
with:
cli_config_credentials_hostname: 'terraform.example.com'
cli_config_credentials_token: ${{ secrets.TF_API_TOKEN }}
The wrapper script installation can be skipped by setting the terraform_wrapper variable to false:
steps:
- uses: hashicorp/setup-terraform@v3
with:
terraform_wrapper: false
Subsequent steps can access outputs when the wrapper script is installed:
steps:
- uses: hashicorp/setup-terraform@v3
- run: terraform init
- id: plan
run: terraform plan -no-color
- run: echo ${{ steps.plan.outputs.stdout }}
- run: echo ${{ steps.plan.outputs.stderr }}
- run: echo ${{ steps.plan.outputs.exitcode }}
Outputs can be used in subsequent steps to comment on the pull request:
Notice: There's a limit to the number of characters inside a GitHub comment (65535).
Due to that limitation, you might end up with a failed workflow run even if the plan succeeded.
Another approach is to append your plan into the $GITHUB_STEP_SUMMARY environment variable which supports markdown.
defaults:
run:
working-directory: ${{ env.tf_actions_working_dir }}
permissions:
pull-requests: write
steps:
- uses: actions/checkout@v4
- uses: hashicorp/setup-terraform@v3
- name: Terraform fmt
id: fmt
run: terraform fmt -check
continue-on-error: true
- name: Terraform Init
id: init
run: terraform init -input=false
- name: Terraform Validate
id: validate
run: terraform validate -no-color
- name: Terraform Plan
id: plan
run: terraform plan -no-color -input=false
continue-on-error: true
- uses: actions/github-script@v7
if: github.event_name == 'pull_request'
env:
PLAN: "terraform\n${{ steps.plan.outputs.stdout }}"
with:
github-token: ${{ secrets.GITHUB_TOKEN }}
script: |
const output = `#### Terraform Format and Style ð\`${{ steps.fmt.outcome }}\`
#### Terraform Initialization âï¸\`${{ steps.init.outcome }}\`
#### Terraform Validation ð¤\`${{ steps.validate.outcome }}\`
<details><summary>Validation Output</summary>
\`\`\`\n
${{ steps.validate.outputs.stdout }}
\`\`\`
</details>
#### Terraform Plan ð\`${{ steps.plan.outcome }}\`
<details><summary>Show Plan</summary>
\`\`\`\n
${process.env.PLAN}
\`\`\`
</details>
*Pusher: @${{ github.actor }}, Action: \`${{ github.event_name }}\`, Working Directory: \`${{ env.tf_actions_working_dir }}\`, Workflow: \`${{ github.workflow }}\`*`;
github.rest.issues.createComment({
issue_number: context.issue.number,
owner: context.repo.owner,
repo: context.repo.repo,
body: output
})
Instead of creating a new comment each time, you can also update an existing one:
defaults:
run:
working-directory: ${{ env.tf_actions_working_dir }}
permissions:
pull-requests: write
steps:
- uses: actions/checkout@v4
- uses: hashicorp/setup-terraform@v3
- name: Terraform fmt
id: fmt
run: terraform fmt -check
continue-on-error: true
- name: Terraform Init
id: init
run: terraform init -input=false
- name: Terraform Validate
id: validate
run: terraform validate -no-color
- name: Terraform Plan
id: plan
run: terraform plan -no-color -input=false
continue-on-error: true
- uses: actions/github-script@v7
if: github.event_name == 'pull_request'
env:
PLAN: "terraform\n${{ steps.plan.outputs.stdout }}"
with:
github-token: ${{ secrets.GITHUB_TOKEN }}
script: |
// 1. Retrieve existing bot comments for the PR
const { data: comments } = await github.rest.issues.listComments({
owner: context.repo.owner,
repo: context.repo.repo,
issue_number: context.issue.number,
})
const botComment = comments.find(comment => {
return comment.user.type === 'Bot' && comment.body.includes('Terraform Format and Style')
})
// 2. Prepare format of the comment
const output = `#### Terraform Format and Style ð\`${{ steps.fmt.outcome }}\`
#### Terraform Initialization âï¸\`${{ steps.init.outcome }}\`
#### Terraform Validation ð¤\`${{ steps.validate.outcome }}\`
<details><summary>Validation Output</summary>
\`\`\`\n
${{ steps.validate.outputs.stdout }}
\`\`\`
</details>
#### Terraform Plan ð\`${{ steps.plan.outcome }}\`
<details><summary>Show Plan</summary>
\`\`\`\n
${process.env.PLAN}
\`\`\`
</details>
*Pusher: @${{ github.actor }}, Action: \`${{ github.event_name }}\`, Working Directory: \`${{ env.tf_actions_working_dir }}\`, Workflow: \`${{ github.workflow }}\`*`;
// 3. If we have a comment, update it, otherwise create a new one
if (botComment) {
github.rest.issues.updateComment({
owner: context.repo.owner,
repo: context.repo.repo,
comment_id: botComment.id,
body: output
})
} else {
github.rest.issues.createComment({
issue_number: context.issue.number,
owner: context.repo.owner,
repo: context.repo.repo,
body: output
})
}
Inputs
The action supports the following inputs:
cli_config_credentials_hostname- (optional) The hostname of a HCP Terraform/Terraform Enterprise instance to place within the credentials block of the Terraform CLI configuration file. Defaults toapp.terraform.io.cli_config_credentials_token- (optional) The API token for a HCP Terraform/Terraform Enterprise instance to place within the credentials block of the Terraform CLI configuration file.terraform_version- (optional) The version of Terraform CLI to install. Instead of a full version string, you can also specify a constraint string (see Semver Ranges for available range specifications). Examples are:"<1.2.0","~1.1.0","1.1.7"(all three installing the latest available1.1version). Prerelease versions can be specified and a range will stay within the given tag such asbetaorrc. If no version is given, it will default tolatest.terraform_wrapper- (optional) Whether to install a wrapper to wrap subsequent calls of theterraformbinary and expose its STDOUT, STDERR, and exit code as outputs namedstdout,stderr, andexitcoderespectively. Defaults totrue.
Outputs
This action does not configure any outputs directly. However, when you set the terraform_wrapper input
to true, the following outputs are available for subsequent steps that call the terraform binary:
stdout- The STDOUT stream of the call to theterraformbinary.stderr- The STDERR stream of the call to theterraformbinary.exitcode- The exit code of the call to theterraformbinary.
License
Code of Conduct
Experimental Status
By using the software in this repository (the "Software"), you acknowledge that: (1) the Software is still in development, may change, and has not been released as a commercial product by HashiCorp and is not currently supported in any way by HashiCorp; (2) the Software is provided on an "as-is" basis, and may include bugs, errors, or other issues; (3) the Software is NOT INTENDED FOR PRODUCTION USE, use of the Software may result in unexpected results, loss of data, or other unexpected results, and HashiCorp disclaims any and all liability resulting from use of the Software; and (4) HashiCorp reserves all rights to make all decisions about the features, functionality and commercial release (or non-release) of the Software, at any time and without any obligation or liability whatsoever.
Contributing
License Headers
All source code files (excluding autogenerated files like package.json, prose, and files excluded in .copywrite.hcl) must have a license header at the top.
This can be autogenerated by installing the HashiCorp copywrite tool and running copywrite headers in the root of the repository.
Top Related Projects
Set up your GitHub Actions workflow with a specific version of node.js
Set up your GitHub Actions workflow with a specific version of Python
Set up your GitHub Actions workflow with a specific version of Java
Set up your GitHub Actions workflow with a specific version of Go
Terragrunt is a flexible orchestration tool that allows Infrastructure as Code written in OpenTofu/Terraform to scale.
Convert
designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot