Running Plan/Apply with Pipelines

Pipelines automatically detects infrastructure changes in your committed IaC and runs Terragrunt Plan or Apply actions on your units. Infrastructure changes in pull/merge request commits targeting Deploy Branch (e.g., main or master) will trigger Terragrunt Plan. Changes in commits directly on the Deploy Branch will trigger Terragrunt Apply.

GitHub

The preferred workflow when working with Pipelines involves creating a new Pull Request with the desired changes, then reviewing the Terragrunt Plan output to ensure the infrastructure changes align with expectations. It is advisable to enforce Branch Protection, particularly the Require branches to be up to date status check. This ensures the PR cannot be merged if the Plan is outdated.

GitLab

The preferred workflow when working with Pipelines involves creating a new Merge Request with the desired changes, then reviewing the Terragrunt Plan output to ensure the infrastructure changes align with expectations. It is advisable to enforce Protected Branches, particularly the Pipeline must succeed requirement. This ensures the MR cannot be merged if the Plan is outdated or fails.

Running plan

To trigger a Plan, create an infrastructure change, such as adding or modifying a terragrunt.hcl unit, on a new branch. Then, open a new merge request/pull request to merge this branch into your Deploy Branch. After merging, Pipelines will comment on the pull request with the Apply output.

Screenshot of Plan Comment

Running apply

To initiate an Apply, merge your changes into the Deploy Branch. Any commits, including merge commits on the Deploy Branch, will trigger an Apply if infrastructure changes are detected.

Pipelines will add a comment to the merged merge request/pull request containing the apply output.

Skipping Pipelines plan/apply

GitHub

In certain scenarios, it may be necessary to skip Pipelines for specific commits. To do this, include one of the workflow skip messages, such as [no ci], in the commit message.

Alternatively, adjust the paths-ignore filter in .github/workflows/pipelines.yml to prevent specific directories from triggering Pipelines.

For example, to exclude a directory named local-testing, update the workflow configuration as follows:

.github/workflows/pipelines.yml

on:
  push:
    branches:
      - main
    paths-ignore:
      # Workflow does not run only if ALL filepaths match the pattern. See https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#example-excluding-paths
      - ".github/**"
      - "local-testing/**"
  pull_request:
    types:
      - opened
      - synchronize
      - reopened
    paths-ignore:
      - "local-testing/**"

GitLab

In certain scenarios, it may be necessary to skip Pipelines for specific commits. To do this, include [skip ci] or [ci skip] in the commit message.

Alternatively, adjust the workflow:rules in your .gitlab-ci.yml to prevent specific directories from triggering Pipelines.

For example, to exclude a directory named local-testing, update the pipeline configuration as follows:

.gitlab-ci.yml

workflow:
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
      changes:
        - "**/*"
        - "!local-testing/**/*"
      when: always
    - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'
      changes:
        - "**/*"
        - "!local-testing/**/*"
      when: always

Destroying infrastructure

To destroy infrastructure, create a commit that removes the relevant Terragrunt unit. Pipelines will detect the deletion and trigger Terragrunt to execute a plan -destroy on pull/merge requests or a destroy on the Deploy Branch. Pipelines automatically retrieves the previous committed version of the infrastructure, enabling Terragrunt to run in the directory that has been deleted.