Convert Figma logo to code with AI

hashicorp logosetup-terraform

Sets up Terraform CLI in your GitHub Actions workflow.

1,541
267
1,541
70

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 Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

setup-terraform

Continuous Integration 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 terraform binary and expose its STDOUT, STDERR, and exit code as outputs named stdout, stderr, and exitcode respectively. (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 to app.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 available 1.1 version). Prerelease versions can be specified and a range will stay within the given tag such as beta or rc. If no version is given, it will default to latest.
  • terraform_wrapper - (optional) Whether to install a wrapper to wrap subsequent calls of the terraform binary and expose its STDOUT, STDERR, and exit code as outputs named stdout, stderr, and exitcode respectively. Defaults to true.

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 the terraform binary.
  • stderr - The STDERR stream of the call to the terraform binary.
  • exitcode - The exit code of the call to the terraform binary.

License

Mozilla Public License v2.0

Code of Conduct

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.