This action automates infrastrucuture orchestration providing shared terraform modules and a terragrunt DRY practices boilerplate. It uses GitHub Actions pipelines to apply infrastructure updates, so you can easily have:

• 1 branch mapping to 1 exclusive private environment
• 1 PR mapping to 1 temporary test environment
• Shared infrastructure in one or more repositories
• Per-service infrastructure in the same repository of the application with minimal impact to developer's project structure
• A real multi-provider experience integrated into the SDLC

This repository is justing cooking some flavorful ingredients: Terraform, Terragrunt, Docker, GitHub Actions.

Table of contents

• Infrastructure as automation
  • Concept
  • Inputs
    • terragrunt_options
    • path
    • gitconfig
  • Outputs
    • state_output
  • Live example
  • An author's note

The main goal of the project is to create a NoOps experience with infrastructure orchestration. If a thing is not infrastructure as code (state declaration) it must be infrastructure as automation (state transition trigger).

Required:heavy_exclamation_mark: Options to pass for terragrunt command execution. Default --terragrunt-debug.

Required:heavy_exclamation_mark: Which directory to use as context (current working directory relative to $GITHUB_WORKSPACE value). Default ''.

Optional gitconfig file content, useful for private repository authentication when the terragrunt/terraform module source is a git URI. Default:

[url "https://git@github.com"]
    insteadOf = "ssh://git@github.com"
[url "https://YOUR_PERSONAL_ACCESS_TOKEN@github.com"]
    insteadOf = "ssh://private@github.com"

The latest output from terragrunt output-all command. You can use this value to get outputs from terraform modules and configure something on your app or any other flow.

This repository is also a proof of concept, so if you have a look at .github/workflows/main.yml file you'll see a workflow declaration to apply the modules of this repository to a Google Cloud project using an Amazon AWS S3 as backend to the terraform state.

And some considerations about the side effects and requirements of this action:

1. We don't require any terragrunt module project structure, you can specify where to execute terragrunt apply-all command using the path. This path is relative to the root of your repository.
2. To setup credentials you can use the standard authentication method of each terraform provider (as they follow the 12 app factor configuration principle). The workflow of this repository uses GitHub Secrets integration with GitHub Actions to retrieve sensitive values in "apply time".
3. To get the benefits from terragrunt's read_terragrunt_config(find_in_parent_folders()) function call you can implement the same configuration as this repository does to owner.hcl file. First we create a secret (OWNER_HCL) with the file content and then a job's step creates the file where it need to be placed.
4. If you want to use the action from other repositories you can't leave the uses: ./ in the workflow declaration. You must put the pattern: UpperGit/terraform-modules@VERSION_TAG where VERSION_TAG substring can be something like v1.

The important thing about this project is the concept, you can easily modify anything to your flavor by forking or cloning it, things done here are highly based on my experience and free to be discussed.