Comments (7)
I think @abtreece raises a valid improvement or feature we could add. For example, the .terragrunt
file could have an option like this:
modules = {
autoUpdate = true
}
When true, we could follow the method suggested by @brikis98 above. False would be the default, and would represent our current behavior.
from terragrunt.
Thanks for filing. This is a limitation of Terraform itself. Perhaps it can be fixed by relying on Git sha1 commit hashes and checking if they changed for each module on each run?
from terragrunt.
Perhaps... I'm going to dig into it further. My Go skills are limited at this point, but I am learning and will try to contribute.
from terragrunt.
Awesome, thanks :)
from terragrunt.
I like ^this^. There is a ref function in the Terraform module source parameter, but adding an option to the terragrunt config would be easier to use and/or an additional fail-safe.
from terragrunt.
Raising this issue from the dead. Not sure I fully understand the feature request here. Is it that Terragrunt will always check the remote to ensure that the code locally matches the code on the remote? E.g. if a module source has ref=foo-bar-branch
, and Terragrunt has already downloaded that module at that ref
, it currently will not download it again, even if a new commit has been pushed to foo-bar-branch
.
If that is indeed the feature request, then --terragrunt-source-update
is a reasonable workaround. This will ensure that the contents of the folder are deleted and will force Terragrunt to download again.
Another option is to pin the ref
to the actual Git commit sha. Any valid Git reference will work for a module source, including the branch, tag, and sha.
Recommend closing this unless I'm missing something!
from terragrunt.
The issue is for a specific use case of terragrunt, where the source modules are local path references. In this case, updates to the module source in the terraform module require a reinit
as terragrunt auto init won't kick in.
In this situation, --terragrunt-source-update
would indeed be a reasonable workaround, and should not be as painful as using a remote source reference given that it is local path copying.
I think it is reasonable to close this given the existence of --terragrunt-source-update
, and the fact that modern terragrunt is built around pulling remote references (in which case this isn't really an issue because the underlying terraform modules would not change unless you update the terraform.source
attribute in terragrunt.hcl
, and that change would trigger auto-init).
from terragrunt.
Related Issues (20)
- test issue please ignore
- sops_decrypt_file function doesn't work with Amazon EKS Pod Identities HOT 2
- `--terragrunt-out-dir` does not work when running `run-all plan` in a leaf directory HOT 2
- Not able to pass inputs as array to Terraform HOT 1
- Provider cache fails when Tailscale VPN is active HOT 1
- Prevent hcl files everywhere with smart projections
- Terragrunt validate-inputs doesn't work with dependency blocks that require mocked values HOT 2
- Scaffold command not handling well multiline description HOT 2
- Caching not working for in-house/local Terraform Providers HOT 1
- Regression: terragrunt-info does not work with mock outputs HOT 2
- Too many Rs in `TERRRAGRUNT_IAM_ASSUME_ROLE_WEB_IDENTITY_TOKEN`
- Improve Context When Logging For State Bucket Updates HOT 2
- CLI argument`--terragrunt-include-dir` includes all folders if the pattern does not match since version `0.50.1` HOT 2
- Add log output before executing external command in GetCredentials
- Dead Provider Caching Link in the Documentation
- Using provider caching with existing `.terraformrc` having `provider_installation` block defined. HOT 2
- Provider caching does not follow "well-known" discovery specification HOT 6
- Highly-parallel deployment with Terragrunt Provider Caching fails with "501 Not Implemented" error HOT 7
- Flaky TestTableTagging HOT 1
- Using provider caching with existing `.terraformrc` having `provider_installation` block defined. HOT 11
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from terragrunt.