Resolving dependencies from multiple merges
We're just starting out with Terragrunt. We merged in a depending module before the dependency had finished deploying. Now, all builds are failing because A didn't get created (not 100% sure why), but B's dependencies aren't met. Am I right in thinking that dependencies must be live before depending modules can be merged in? How do I fix a situation where neither the depending NOR the dependency are live, thus causing all builds to fail? I tried deleting the depending module from the S3 bucket, but that didn't seem to make a difference. I have also tried pushing directly to main instead of doing a PR, but that didn't do anything either. Clarification note: I don't have a circular dependency in the traditional sense. I tried to create a resource, and before it had fully come up, I merged in another resource addition, which then failed to start. A does not depend on B, simply put. A didn't exist which the CircleCI build for B was running, so B failed it's build, but was merged in. A failed to start at all, so now we're stuck. --- <ins datetime="2022-05-02T18:16:43Z"> <p><a href="https://gruntwork.zendesk.com/agent/tickets/108534">Tracked in ticket #108534</a></p> </ins>
The CI scripts use a diff based model to identify which modules to deploy. That is, it sees what changed on the last commit and only attempt to deploy those. This is most likely why "nothing is happening" - the commits aren't containing changes to the modules that you want the CI to deploy. In general, you can force deployments on any module by adding a nonce changes to those modules. For example, you can generate a random hash/uuid and add that as a comment to the `terragrunt.hcl` file for the module you want to force the CI to deploy. Given that, you can create a new commit that modifies the `terragrunt.hcl` for A with a superficial change (e.g., adding whitespace or a nonce comment) to force the CI build to attempt to deploy A. From there, you can try to see what is causing A to fail in the deployment. Once A is deployed, you can then do the same thing to B to get it to deploy. Note that we typically recommend using `terragrunt` locally to resolve issues like this for faster iteration. It will also allow you to perform state surgery (`state rm`, `state mv`, or `import`) to fix corruption issues as well, which I suspect would be in play here if you deleted the S3 state file. Once everything is resolved to reach steady state, then you can go back to relying on the CI builds for standard deployments.