New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
.terragrunt-cache fails to update with new source "...?ref=..." #764
Comments
Just to make sure I understand:
|
The first time i run Until I update the commit reference in If I delete the |
Ah, OK, thanks for the clarification. Sounds like some sort of bug with the cleanup code. This was changed recently: https://github.com/gruntwork-io/terragrunt/blob/master/cli/download_source.go#L332. Anyone have time to dig in and submit a PR? |
Did a The "after" is missing |
terrragrunt uses go-getter to download sources. On subsequent source get, go-getter library pulls the changes with Since https://github.com/gruntwork-io/terragrunt/blob/master/cli/download_source.go#L332 cleans everything but whitelisted files, there is no |
@ekini Good find! Anyone have time for a PR to fix that issue? |
I've had a look and the easiest workaround would be to exclude So I don't see an easy solution from this side. If yes, then maybe instead of cleaning the dir here https://github.com/gruntwork-io/terragrunt/blob/master/cli/download_source.go#L332, it would be possible to do something like |
We have to clean up the download dir due to iterative development. E.g., You are running An |
This is hurting our deploys quite a lot, breaks the live repo/module repo workflow - I'm pretty sure this didn't happen with 0.19.0, not had a chance to bisect fully. |
If nobody wants to handle this, I can try in a couple of days :) My thoughts are: in this function get a list of files in |
@ekini That would be great! |
That allows to safely delete only the files we copied on the previous copy, not worrying about stale files still living in the working directory. Removes some unused functions. Fixes gruntwork-io#764
Created a PR #774 |
We are having the same issue when pointing the source at specific tag(lets say Thank you for working on it. Hopefully it will fix our case too. So far we have been just wiping the cache folder when the issue occurs, but that is a bit cumbersome as it requires redownloading providers which takes a minute or two. |
I built terragrunt from the PR #774 to try and repair our workflow, however the same problem as described at the top of the PR seems to persist. I will double check the build. I'm also a bit puzzled as to how this is not effecting everyone who uses Terragrunt - this seems a bad break to a key feature (immutable version modules). Am I missing something? |
@mattford63 What are you referencing in |
Hi @spaszek I'm referencing tags. |
@mattford63 could you please ensure you are using the PR#774 terragrunt version? Because that version removes only the files that were copied from the terragrunt module folder. |
@mattford63 then could you please give more details? What files you have in the terragrunt module dir, in the source dir and in the working dir? Like in the starting comment. Maybe after patching terragrunt you need to delete the working directory once, because |
Excluding the .git directory from the cache can cause issues with Terragrunt with a remote git source (gruntwork-io/terragrunt#764)
I'm updating my
terragrunt.hcl
'sterraform { source = "..." } }
value with new...?ref=<commit>
values as I make adjustments, but terragrunt isn't successfully pulling the new commit from the git repo. Instead, it complains...The hash subdirectories under
.terraform-cache
are always the same:If I delete
.terragrunt-cache
entirely, then it's able to pull the new commit reference. I've also tested to make sure it's actually pulling the specified commit and not just HEAD.terraform 0.12.2 (via brew)
terragrunt 0.19.4 (via brew)
git 1.22.0 (via brew)
macOS mojave
The text was updated successfully, but these errors were encountered: