Would it be possible to include Terragrunt support with an example?

[danielmapar]

Is your feature request related to a problem

I would love to try this tool with my current Terragrunt setup. However, I don't see how I could integrate it with your tool.

Describe the solution you'd like

Besides installing and setting up Terraform, I wish to setup Terragrunt and have commands such as apply-all, plan-all, init-all, delete-all and others to be encompassed by this workflow.

Describe alternatives you've considered

I am considering using the Terragrunt github actions workflow, but it does not support triggering actions via comments. https://github.com/gruntwork-io/terragrunt-action

Additional context

N/A

[rdhar]

Hey @danielmapar, I'm a fan of this feature request! And you've raised it at the perfect time, just ahead of the upcoming v11 major version release. There're a few points of interest worth mentioning:

• The biggest one: this Action is moving away from comments-trigger (i.e., issue_comment) since GitHub's support for this trigger is extremely limited. It doesn't even support basic filters like paths or branches, and nor is there any native protection for escaping/passing any ol' Bash input command directly.
  • Instead, efforts will be focused on pull_request trigger, which is supported (and used) far more extensively.
  • As a compromise to meet the needs of interactive trigger, pull_request also supports labeled activity type, which can be leveraged to manually trigger commands based on the PR label used.
• In a spot of good news: there's going to be built-in support for tenv, which is the most popular open-source version manager for TF binaries, including: OpenTofu, Terraform, and Terragrunt.
  • Although Terragrunt will be included, I'd need to include support for each of its commands' arguments just like with Terraform plan, for example. Would you mind sharing a similar list for Terragrunt where the CLI options are documented?

[danielmapar]

@RDhar that sounds great! Thanks for the updates, excited to see the new release.

I would say the top 1 command one needs to support for Terragrunt is: terragrunt run-all plan/apply/destroy. Terragrunt itself implements all base Terraform commands as well, more here.

run-all pretty much runs plan/apply/destroy/etc in multiple folders that contain a terragrunt.hcl file. That may lead to an insanely big output (just a heads up). Another important thing to point out is that having the power to supply CLI flags would be extremely important for Terragrunt. One example would be running terragrunt run-all plan --terragrunt-working-dir ~/XYZ.

I am not sure if that will impact your implementation, but it is also worth noting that Terragrunt creates multiple tfstate files (one per folder containing a terragrunt.hcl file). It also creates s3 buckets and even dynamodb tables automatically. That means you may have multiple tfstates inside the same s3 bucket for example. More info on that here.

Once again, fantastic project. Keep me posted if you have any further questions.

[danielmapar]

One fantastic project to use as a benchmark to validate your github action is the terragrunt-infrastructure-live-example. It is a sample project implementing all best practices for Terragrunt and contains the general anatomy of a Terragrunt project. This live example is supported by Gruntworks (aka the creators of Terragrunt).

Not sure if it helps, but Terragrunt also has its own github action terragrunt-action. That may give you some insights on how it works.

[rdhar]

Hi @danielmapar, here to share a small but unhelpful update. This is still on my radar and something I'd love to implement support for. Unfortunately, I'm struggling to reconcile Terragrunt's wrapper within TF-via-PR.

With this Action acting as the thinnest of wrappers around Terraform/Tofu to render their CLI output in a formatted PR comment, it seems to me too basic to handle Terragrunt configuration.

To give an example, let's take the process of running a plan across multiple directories and storing the associated TF plan files. TF-via-PR requires the directory paths (from arg_chdir input) in order to know where to exec TF plan as well as upload the resulting TF plan file artifact. This can be done across multiple directories simultaneously using matrix strategy, as demonstrated here using workspaces/var-files inputs.

Were it to support Terragrunt's run-all plan, TF-via-PR would somehow need to recursively search through folders of the current working directory in order to identify all of the TF plan files for upload. Unlike the parallel jobs run in matrix strategy, this Action would also need to consolidate various outputs of run-all plan in one PR comment, or perhaps one PR comment for each folder.

Given that Gruntwork manages both the live-example and terragrunt-action, there must be repo where both are combined to demonstrate a "real-life" usage scenario of Terragrunt in GitHub Actions CI, right?

[rdhar]

Hi @danielmapar, following the recent v12 release, TF-via-PR has been re-written in pure Bash (read highlights). Aside from a 55% reduction in codebase and zero external dependencies, we've consolidated Terraform/OpenTofu CLI operations to lower the barrier to entry for contribution and maintenance.

With that said, I'm still keen on implementing Terragrunt support, and think the current setup is geared towards it. However, I no longer get to use Terragrunt on a day-to-day basis and largely reliant on reading docs on how it operates.

On that note, the first hurdle I see is the handling of plan files. More specifically, currently users pass in their working-directory, wherein TF plan is carried out and the resulting plan file is uploaded from that directory. With Terragrunt, I understand plan-all goes into multiple different directories to carry out plans. What're some ways to track where the resultant plan files are generated, and if they follow a naming convention?

[rdhar]

Closing out for now until we can allocate time & resources to address.