action.yaml

name: terraform-apply
description: Apply a Terraform plan
author: Daniel Flook

inputs:
  path:
    description: Path to the Terraform root module to apply
    required: false
    default: "."
  workspace:
    description: Terraform workspace to run the apply in
    required: false
    default: "default"
  label:
    description: |
      A friendly name for the environment the Terraform configuration is for.
      This will be used in the PR comment for easy identification.

      It must be the same as the `label` used in the corresponding [`dflook/terraform-plan`](https://github.com/dflook/terraform-github-actions/tree/main/terraform-plan) action.
    required: false
    default: ""
  variables:
    description: |
      Variables to set for the terraform plan. This should be valid Terraform syntax - like a [variable definition file](https://developer.hashicorp.com/terraform/language/values/variables#variable-definitions-tfvars-files).

      Variables set here override any given in `var_file`s.
    required: false
  var_file:
    description: |
      List of tfvars files to use, one per line.
      Paths should be relative to the GitHub Actions workspace
    required: false
  backend_config:
    description: List of Terraform backend config values, one per line.
    required: false
    default: ""
  backend_config_file:
    description: |
      List of Terraform backend config files to use, one per line.
      Paths should be relative to the GitHub Actions workspace
    required: false
    default: ""
  replace:
    description: List of resources to replace, one per line.
    required: false
    default: ""
  target:
    description: |
      List of resources to apply, one per line.
      The apply operation will be limited to these resources and their dependencies.
    required: false
    default: ""
  destroy:
    description: |
      Set to `true` to destroy all resources.

      This generates and applies a plan in [destroy mode](https://developer.hashicorp.com/terraform/cli/commands/plan#planning-modes).
    required: false
    default: "false"
  refresh:
    description: |
      Set to `false` to skip synchronisation of the Terraform state with actual resources.

      This will make the plan faster but may be out of date with the actual resources, which can lead to incorrect plans.
    required: false
    default: "true"
  plan_path:
    description: |
      Path to a plan file to apply. This would have been generated by a previous [`dflook/terraform-plan`](https://github.com/dflook/terraform-github-actions/tree/main/terraform-plan) action.

      The default behaviour when this is not set is to generate a plan from the current configuration and compare it to the plan attached to the PR comment.
      If it is logically the same, the plan will be applied.

      When this is set to a plan file, the plan will not be generated again. If it is the exact same plan as the one attached to the PR comment, it will be applied.
      This will be faster than generating a new plan.

      There are downsides to applying a stored plan:

      - The plan may contain sensitive information so must be stored securely, possibly outside of GitHub.
      - It does not account for any changes that have occurred since it was generated, and may no longer be correct.
      - Plans must be generated and applied in strict order. Multiple open PRs will cause conflicts if they are applied out of order.
      - Plans are not portable between platforms.
      - Terraform and provider versions must match between the plan generation and apply.

      When `auto_approve` is set to `true`, the plan will be applied without checking if it is the same as the one attached to the PR comment.
    required: false
    default: ""
  auto_approve:
    description: |
      When set to `true`, plans are always applied.

      The default is `false`, which requires plans to have been added to a pull request comment.
    required: false
    default: "false"
  parallelism:
    description: Limit the number of concurrent operations
    required: false
    default: "0"

outputs:
  json_plan_path:
    description: |
      This is the path to the generated plan in [JSON Output Format](https://www.terraform.io/docs/internals/json-format.html).
      The path is relative to the Actions workspace.

      Terraform plans often contain sensitive information, so this output should be treated with care.

      This won't be set if the backend type is `remote` - Terraform does not support saving remote plans.
  text_plan_path:
    description: |
      This is the path to the generated plan in a human-readable format.
      The path is relative to the Actions workspace.
      This won't be set if `auto_approve` is true while using a `remote` backend.
  failure-reason:
    description: |
      When the job outcome is `failure`, this output may be set. The value may be one of:

      - `apply-failed` - The Terraform apply operation failed.
      - `plan-changed` - The approved plan is no longer accurate, so the apply will not be attempted.
      - `state-locked` - The Terraform state lock could not be obtained because it was already locked.

      If the job fails for any other reason this will not be set.
      This can be used with the Actions expression syntax to conditionally run steps.
  lock-info:
    description: |
      When the job outcome is `failure` and the failure-reason is `state-locked`, this output will be set.

      It is a json object containing any available state lock information and typically has the form:

      ```json
      {
        "ID": "838fbfde-c5cd-297f-84a4-d7578b4a4880",
        "Path": "terraform-github-actions/test-unlock-state",
        "Operation": "OperationTypeApply",
        "Who": "root@e9d43b0c6478",
        "Version": "1.3.7",
        "Created": "2023-01-28 00:16:41.560904373 +0000 UTC",
        "Info": ""
      }
      ```
  run_id:
    description: If the root module uses the `remote` or `cloud` backend in remote execution mode, this output will be set to the remote run id.
  json_output_path:
    description: |
      This is the path to all the root module outputs in a JSON file.
      The path is relative to the Actions workspace.

      For example, with the Terraform config:

      ```hcl
      output "service_hostname" {
        value = "example.com"
      }
      ```

      The file pointed to by this output will contain:

      ```json
      {
        "service_hostname": "example.com"
      }
      ```

      Terraform list, set and tuple types are cast to a JSON array, map and object types are cast to a JSON object.

runs:
  using: docker
  image: ../image/Dockerfile
  entrypoint: /entrypoints/apply.sh

branding:
  icon: globe
  color: purple