pre-commit-terraform VS terragrunt

repos: - repo: https://github.com/pre-commit/pre-commit-hooks rev: v4.3.0 hooks: - id: end-of-file-fixer - id: trailing-whitespace - repo: https://github.com/antonbabenko/pre-commit-terraform rev: v1.72.2 hooks: - id: terraform_fmt - id: terraform_tflint - id: infracost_breakdown args: - --args=--path=./ verbose: true # Always show costs - id: terraform_validate

repos: # pre-commit install --hook-type pre-push - repo: https://github.com/pre-commit/pre-commit-hooks # Generic review/format rev: v4.6.0 hooks: - id: end-of-file-fixer - id: no-commit-to-branch args: ["--branch", "master"] - id: trailing-whitespace - repo: https://github.com/igorshubovych/markdownlint-cli # Format markdown rev: v0.40.0 hooks: - id: markdownlint args: ["--fix", "--disable", "MD036"] - repo: https://github.com/antonbabenko/pre-commit-terraform rev: v1.89.1 # Get the latest from: https://github.com/antonbabenko/pre-commit-terraform/releases hooks: - id: terraform_fmt - id: terraform_tflint - id: terraform_validate args: - --args=-json - --args=-no-color - id: terraform_docs args: - --hook-config=--path-to-file=README.md - --hook-config=--add-to-existing-file=true

Personally I use pre-commit with some of these hooks in addition to some default hooks. It's basically a localised CI pipeline, and also means every commit has passed checks so keeps your commit history neat. Way faster to develop infrastructure code and fix issues than having to keep pushing to the remote repo and waiting for an Action to run.

https://github.com/antonbabenko/pre-commit-terraform because Terraform/Terragrunt configs should be documented, tidy and valid all the time :)

Local testing with pre-commit-terraform. Formats code with terraform fmt Validates code with terraform validate Automatic README updates with terraform-docs. Static code analysis with TFLint, tfsec and checkov.

diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml index ca47c31..3e5cfef 100644 --- a/.pre-commit-config.yaml +++ b/.pre-commit-config.yaml @@ -22,7 +22,10 @@ repos: rev: v2.7.1 hooks: - id: prettier - types_or: [yaml, markdown, json] + types_or: [yaml, markdown, json, html] + additional_dependencies: + - "[email protected]" + - "[email protected]" - repo: https://github.com/antonbabenko/pre-commit-terraform rev: v1.74.1 hooks:

pre-commit-terraform – Pre-commit git hooks for automation

Let me share a shameless plug (as an author of the pre-commit-terraform). I will show these hooks in action and answer questions during my live stream on Friday 29th of October - https://www.youtube.com/watch?v=ziJK79tI6tY

Terraform. I use it to manage infrastructure. It simplifies many things if at least a few people work on a project. As the project grows, it becomes massive, and maybe for better state management, you will need tools like Terragrunt to keep infrastructure-related code simple. If you use AWS as a cloud provider, you can also use AWS CDK. It’s a nice tool with Typescript support, but it’s available only for AWS, and if you need something from a different cloud infrastructure, the code will be much more complex than Terraform. That’s why I prefer the Terraform even for AWS.

You need to ensure your Action code is built before you attempt a terrform plan or apply. In our case we are using terragrunt which has a helpful before_hook, setup in the terragrunt.hcl file as follows:

https://github.com/hashicorp/terraform/issues/19932

My understanding is that people that have this as a first-class concern use something like Terragrunt to dynamically generate the HCL as needed.

https://terragrunt.gruntwork.io/

For Burrow here, I was was focused on shipping something and didn't want to spend time on generating that code just yet. But the project has gotten some attention so if this is a recurring request I'll probably do it.

Note that I intentionally chose the 17 AWS regions that are default enabled in every new AWS account, so it should only be if you want to customize it that this becomes important.

A Cloudformation Stacks based deployment to achieve multi-region would be another good (and perhaps better) option here. I could add that to the Makefile, with inspiration from your link there.

Terragrunt started to use OpenTofu as the default IAC tool, however, this was not a major release; instead, it was provided as a patch and users didn't expect to have any differences in the behavior. The original problem may be found here.

Next, head over to the Terragrunt GitHub page to download it.

Terragrunt is a Terraform wrapper, designed to fill in the gaps when it comes to large scale Terraform configurations.

‍Terragrunt is a thin wrapper that provides extra tools for keeping your Terraform configurations DRY (Don't Repeat Yourself), working with multiple Terraform modules, and managing remote state. It's particularly useful in managing large-scale infrastructure deployments with Terraform.

Our first attempt was to introduce other engineering teams to Terraform - the Platform team was already using it extensively with Terragrunt, and using Atlantis to automate plan and apply operations in a Git flow to ensure infrastructure was consistent. We'd written modules, with documentation, and an engineer would simply need to raise a PR to use the module and provide the right values, and Atlantis (once the PR was approved by Platform) would go ahead and set it up for them.