This is one of a suite of Terraform related actions - find them at dflook/terraform-github-actions.
This actions generates a Terraform plan. If the triggering event relates to a PR it will add a comment on the PR containing the generated plan.
The GITHUB_TOKEN
environment variable must be set for the PR comment to be added.
The action can be run on other events, which prints the plan to the workflow log.
The dflook/terraform-apply action can be used to apply the generated plan.
path
Path to the Terraform root module to apply
workspace
Terraform workspace to run the plan for
default
label
A friendly name for the environment the Terraform configuration is for. This will be used in the PR comment for easy identification.
If set, must be the same as the label
used in the corresponding terraform-apply
command.
variables
Variables to set for the terraform plan. This should be valid Terraform syntax - like a variable definition file.
with:
variables: |
image_id = "$"
availability_zone_names = [
"us-east-1a",
"us-west-1c",
]
Variables set here override any given in var_file
s.
var_file
List of tfvars files to use, one per line. Paths should be relative to the GitHub Actions workspace
with:
var_file: |
common.tfvars
prod.tfvars
backend_config
List of Terraform backend config values, one per line.
with:
backend_config: token=$
backend_config_file
List of Terraform backend config files to use, one per line. Paths should be relative to the GitHub Actions workspace
with:
backend_config_file: prod.backend.tfvars
replace
List of resources to replace, one per line.
with:
replace: |
random_password.database
target
List of resources to apply, one per line. The plan will be limited to these resources and their dependencies.
with:
target: |
kubernetes_secret.tls_cert_public
kubernetes_secret.tls_cert_private
destroy
Set to true
to generate a plan to destroy all resources.
This generates a plan in destroy mode.
add_github_comment
Controls whether a comment is added to the PR with the generated plan.
The default is true
, which adds a comment to the PR with the results of the plan.
Set to changes-only
to add a comment only when the plan indicates there are changes to apply.
Set to always-new
to always create a new comment for each plan, instead of updating the previous comment.
Set to false
to disable the comment - the plan will still appear in the workflow log.
parallelism
Limit the number of concurrent operations
GITHUB_TOKEN
The GitHub authorization token to use to create comments on a PR.
The token provided by GitHub Actions can be used - it can be passed by
using the $
expression, e.g.
env:
GITHUB_TOKEN: $
The token provided by GitHub Actions has default permissions at GitHub’s whim. You can see what it is for your repo under the repo settings.
The minimum permissions are pull-requests: write
.
It will also likely need contents: read
so the job can checkout the repo.
You can also use any other App token that has pull-requests: write
permission.
You can use a fine-grained Personal Access Token which has repository permissions:
You can also use a classic Personal Access Token which has the repo
scope.
The GitHub user or app that owns the token will be the PR comment author.
TERRAFORM_ACTIONS_GITHUB_TOKEN
When this is set it is used instead of GITHUB_TOKEN
, with the same behaviour.
The GitHub Terraform provider also uses the GITHUB_TOKEN
environment variable,
so this can be used to make the github actions and the Terraform provider use different tokens.
GITHUB_DOT_COM_TOKEN
This is used to specify a token for GitHub.com when the action is running on a GitHub Enterprise instance. This is only used for downloading OpenTofu binaries from GitHub.com. If this is not set, an unauthenticated request will be made to GitHub.com to download the binary, which may be rate limited.
TERRAFORM_CLOUD_TOKENS
API tokens for cloud hosts, of the form <host>=<token>
. Multiple tokens may be specified, one per line.
These tokens may be used with the remote
backend and for fetching required modules from the registry.
e.g:
env:
TERRAFORM_CLOUD_TOKENS: app.terraform.io=$
With other registries:
env:
TERRAFORM_CLOUD_TOKENS: |
app.terraform.io=$
terraform.example.com=$
TERRAFORM_SSH_KEY
A SSH private key that Terraform will use to fetch git/mercurial module sources.
This should be in PEM format.
For example:
env:
TERRAFORM_SSH_KEY: $
TERRAFORM_HTTP_CREDENTIALS
Credentials that will be used for fetching modules sources with git::http://
, git::https://
, http://
& https://
schemes.
Credentials have the format <host>=<username>:<password>
. Multiple credentials may be specified, one per line.
Each credential is evaluated in order, and the first matching credentials are used.
Credentials that are used by git (git::http://
, git::https://
) allow a path after the hostname.
Paths are ignored by http://
& https://
schemes.
For git module sources, a credential matches if each mentioned path segment is an exact match.
For example:
env:
TERRAFORM_HTTP_CREDENTIALS: |
example.com=dflook:$
github.com/dflook/terraform-github-actions.git=dflook-actions:$
github.com/dflook=dflook:$
github.com=graham:$
TF_PLAN_COLLAPSE_LENGTH
When PR comments are enabled, the terraform output is included in a collapsable pane.
If a terraform plan has fewer lines than this value, the pane is expanded by default when the comment is displayed.
env:
TF_PLAN_COLLAPSE_LENGTH: 30
TERRAFORM_PRE_RUN
A set of commands that will be ran prior to terraform init
. This can be used to customise the environment before running Terraform.
The runtime environment for these actions is subject to change in minor version releases. If using this environment variable, specify the minor version of the action to use.
The runtime image is currently based on debian:bullseye
, with the command run using bash -xeo pipefail
.
For example:
env:
TERRAFORM_PRE_RUN: |
# Install latest Azure CLI
curl -skL https://aka.ms/InstallAzureCLIDeb | bash
# Install postgres client
apt-get install -y --no-install-recommends postgresql-client
changes
Set to ‘true’ if the plan would apply any changes, ‘false’ if it wouldn’t.
plan_path
This is the path to the generated plan in an opaque binary format. The path is relative to the Actions workspace.
The plan can be used as the plan_file
input to the dflook/terraform-apply action.
Terraform plans often contain sensitive information, so this output should be treated with care.
json_plan_path
This is the path to the generated plan in JSON Output Format The path is relative to the Actions workspace.
Terraform plans often contain sensitive information, so this output should be treated with care.
text_plan_path
This is the path to the generated plan in a human-readable format. The path is relative to the Actions workspace.
to_add
to_change
to_destroy
to_move
to_import
The number of resources that would be affected by each type of operation.
run_id
If the root module uses the remote
or cloud
backend in remote execution mode, this output will be set to the remote run id.
When adding the plan to a PR comment (add_github_comment
is not false
), the workflow can be triggered by the following events:
When add_github_comment
is set to false
, the workflow can be triggered by any event.
This event triggers workflows when a comment is made in a Issue, as well as a Pull Request. Since running the action will only work in the context of a PR, the workflow should check that the comment is on a PR before running.
Also take care to checkout the PR ref.
jobs:
plan:
if: $
runs-on: ubuntu-latest
env:
GITHUB_TOKEN: $
steps:
- name: Checkout
uses: actions/checkout@v4
with:
ref: refs/pull/$/merge
- name: terraform apply
uses: dflook/terraform-plan@v1
with:
path: my-terraform-config
The pushed commit must have come from a Pull Request. Typically this is used to trigger a workflow that runs on the main branch after a PR has been merged.
This event can be used to trigger a workflow from another workflow. The client payload must include the pull_request api url of where the plan PR comment should be added.
A minimal example payload looks like:
{
"pull_request": {
"url": "https://api.github.com/repos/dflook/terraform-github-actions/pulls/1"
}
}
This example workflow runs on every push to an open pull request, and create or updates a comment with the terraform plan
name: PR Plan
on: [pull_request]
permissions:
contents: read
pull-requests: write
jobs:
plan:
runs-on: ubuntu-latest
name: Create terraform plan
env:
GITHUB_TOKEN: $
steps:
- name: Checkout
uses: actions/checkout@v4
- name: terraform plan
uses: dflook/terraform-plan@v1
with:
path: my-terraform-config
This example workflow demonstrates most of the available inputs:
production
, and the plan will use the prod
workspace.env/prod.tfvars
, with turbo_mode
overridden to true
.env/prod.backend
, and the token is set from a secret.name: PR Plan
on: [pull_request]
env:
GITHUB_TOKEN: $
TERRAFORM_CLOUD_TOKENS: terraform.example.com=$
TERRAFORM_SSH_KEY: $
permissions:
contents: read
pull-requests: write
jobs:
plan:
runs-on: ubuntu-latest
name: Create Terraform plan
steps:
- name: Checkout
uses: actions/checkout@v4
- name: terraform plan
uses: dflook/terraform-plan@v1
with:
path: my-terraform-config
label: production
workspace: prod
var_file: env/prod.tfvars
variables: |
turbo_mode=true
backend_config_file: env/prod.backend
backend_config: token=$
This workflow generates a plan on demand, triggered by someone
commenting terraform plan
on the PR. The action will create or update
a comment on the PR with the generated plan.
name: Terraform Plan
on: [issue_comment]
permissions:
contents: read
pull-requests: write
jobs:
plan:
if: $
runs-on: ubuntu-latest
name: Create Terraform plan
env:
GITHUB_TOKEN: $
steps:
- name: Checkout
uses: actions/checkout@v4
with:
ref: refs/pull/$/merge
- name: terraform plan
uses: dflook/terraform-plan@v1
with:
path: my-terraform-config