Closed mborbely closed 1 week ago
Hi,
usually caching of .terragrunt-cache
helps to improve the performance of execution, and is not mandatory to set TERRAGRUNT_DOWNLOAD
- can be cached individual .terragrunt-cache
folder.
This is likely fixed by this https://github.com/gruntwork-io/terragrunt/issues/1212#issuecomment-2047947895.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for raising this issue.
This was fixed by that issue linked by @GMartinez-Sisti . Thanks for highlighting that.
Main question
I have the following question: is it a good idea to use the caching capability of CI tools to cache the .terragrunt-cache files as a performance improvement? In other words, is it going to cause problems to keep this cache between builds? Side note: we should mention that the TERRAGRUNT_DOWNLOAD variable, and hence a central download location could also be included in the solution, but it feels like a minor detail that wouldn't change the answer.
My best guess based on what I've experienced with local builds is that the above solution would cause problems. But maybe the commands we've been using just weren't robust enough, and maybe there are better alternatives.
Background
The above section sums up my main question, but I'd like to add some details on why this is becoming important. We have a terragrunt repository with relatively lots of leaf modules. The entry point in our CI pipeline is a
run-all plan
command. Unfortunately lately this command has been becoming slow, mostly due to repeated downloads. For this reason we started looking at optimizations with terraform'splugin_cache_dir
configuration.However, this meant that we ran into the problem defined by this issue. Therefore, we had to upgrade our terragrunt version to v0.50.11. But this comes with a huge price: every init command now has to happen synchronuosly, which in turn means that the pipeline is almost as slow as it used to be before any of the optimizations.
One optimization that would come to mind is ditching the
plugin_cache_dir
approach and using a repository mirror instead. But this approach would cause recurring manual work. I'm just wondering: is there a solution that would achieve reasonable performance without any of these manual interventions?