Hi everyone, question: given that terragrunt requires you to set the sources for each module, how do you deal with module versions, even better across multiple accounts? Even just with one account I already have 4 cloudposse modules just for networking (2 labels, vpc and dynamic subnets), 2 for EKS (cluster and nodegroup), 1 for RDS and likely 3 or 4 for ECS, that’s at least 10 version to keep track of, and there are already 4 of those accounts, having to keep track and update all those versions manually is not really ideal.. I have tried
terrafile, but - while it works great using pure terragrunt (setting the source into the
terragrunt.hcl ) thanks to the
find_in_parent_folders function which manages to get the module from the terrafile local “cache”, it fails using local modules because there’s no way to set a relative path as a source targeting the terrafile’s modules path into the root of terragrunt from the
.terragrunt-cache. I hope it makes sense. Anyway, no luck with terrafile, the only way would be to create these local modules as git repos, and reference everything in
terragrunt.hcl files, I’m not really happy to do so, because that would mean to add git auth to these deployments (or make them public) and maintain those modules which I would do just because of this issue. How did you sort this issue?
Dependabot, or renovatebot
Yea, I think what @loren recommends is the terragrunt best practice. I think that’s great for modules, but we take a starkly different approach with root modules with atmos (https://atmos.tools). In Atmos, we recommend using release channels, and decoupling deployment from release. That way you can easily see the blast radius of changes anywhere a component is used, and release changes based on a cadence that suits you. This ensures that all environments converge on the same versions of root modules without DoS by PR.
Atmos is a workflow automation tool for DevOps to manage complex configurations with ease. It’s compatible with Terraform and many other tools.
I think renovatebot has a feature already to create a single pr with multiple updates. Dependabot has an issue open to add that feature, but it’s not there yet.
I think renovatebot has a feature already to create a single pr with multiple updates. Can it do that by path? I think that would be needed for infrastructure monorepos
How to reduce the