There are 2 ways of using Digger with Terragrunt:

• individual projects
• dynamically generated projects

​

Individual projects

Demo repo

Digger uses a single terragrunt project if you just list it as a project as follows:

projects:
- name: dev
  dir: dev
  terragrunt: true

This will perform a terragrunt apply after changes are detected within this directory.

​

Dynamically generating Terragrunt projects

Demo repo

In many cases with terragrunt you don’t want to mention all of your terragrunt components since there can be tens or hundreds of those (not to mention all the dependencies of those). In this case you can just leave it to digger and it will perform dynamic generation of projects for you before triggering the relevant terragrunt apply commands on all impacted projects per pull request. It will also handle dependencies of these projects. You can configure this using the following:

generate_projects:
  terragrunt_parsing:
    parallel: true
    createProjectName: true
    createWorkspace: true
    defaultWorkflow: default
workflows:
  default:
    plan:
      steps:
        - init
        - plan
        - run: echo "Terragrunt generation!"

And the workflow for this needs to use setup-terragrunt: true as follows:

name: Digger

on:
  workflow_dispatch:

jobs:
  digger-job:
    runs-on: ubuntu-latest
    steps:
      - uses: diggerhq/digger@vLatest
        with:
          setup-terragrunt: true
          terragrunt-version: 0.44.1

​

Note regarding SOPS

Since currently the generation happens in the backend where no access to SOPS variables exist this means that if you use sops_decrypt_file in your terragrunt.hcl it will lead to an exception of sops decryption failed. Current workaround is to use environment variable DIGGER_GENERATE_PROJECT and check if its true as follows:

locals {
  secrets = get_env("DIGGER_GENERATE_PROJECT", "false") == "true" ? {} : yamldecode(sops_decrypt_file("secrets.yaml"))
}

This will ensure that an exception doesn’t occur during generation in the backend.