terragrunt
terragrunt copied to clipboard
[WIP] Add a "output-module-groups" command
Description
Fixes #2016 .
This PR introduces the terragrunt groups-json
command which outputs as JSON the groups of modules
(as an array of array) of the current stack.
TODOs
Read the Gruntwork contribution guidelines.
- [ ] Update the docs.
- [ ] Run the relevant tests successfully, including pre-commit checks.
- [x] Include release notes. If this PR is backward incompatible, include a migration guide.
Release Notes (draft)
Added the "groups-json" command.
- [ ] Update the docs.
@denis256 before updating docs, do you have a suggestion that is better than "groups-json" for the command name ?
- [ ] Run the relevant tests successfully, including pre-commit checks.
The PR doesn't modify any code, though, I should probably add some tests ?
Hi,
since is related to reading output, I was thinking about something output-xxx
Hi,
since is related to reading output, I was thinking about something output-xxx
@smaftoul thank you for the PR! I am very excited to see it might be implemented soon 🤞 🙏
@CarterSheehan Hi ! Thanks for pinging, I stopped working on this because I have been fired (like a lot of startups are laying off) and took some holidays ... I should definitely finish this feature, as it almost already works !
@smaftoul I like this feature a lot for cicd, but I am not clear exactly how it is intended to be used. When I run it, I just get the same module list as normal, except it is in json (which is useable, but takes a lot of additional work). What I was thinking would be most useful and applicable to cicd would be to run a command at the root that will automatically
- get module groups
- for Group1, run a
plan
for all modules and check if there are any changes - if there are changes, output a plan file and exit (ci tools can then post this for human review, which will then get ingested into an
apply
- if there are no changes to Group1, then move on to Group2
This nicely separates each dependency layer in your stack, and ensures that you have as much knowledge as possible about each deployment's consequences. No more having to fiddle around with "mock outputs", because modules only have a plan attempted when all previous-order modules have no pending changes.
Wish I could help, but I am still learning Go
Would love to see this @smaftoul ! I believe that this output can enable you to code what you are describing @phillip-constantine, but I don't think the whole process should be managed by Terragrunt.
I've added the documentation required :)
Thanks @Laudenlaruto, getting this PR out of WIP ... after 9 month waiting for a bit of doc ;)
@denis256 can I request a review on this ?
Hey @denis256 can I request a review ? :)
[INFO] Initializing environment for https://github.com/gruntwork-io/pre-commit.
Terraform fmt............................................................Passed
goimports................................................................Failed
- hook id: goimports
- files were modified by this hook
cli/cli_app.go
configstack/module.go
configstack/module.go
cli/cli_app.go
configstack/module.go
Up on the review @denis256 :)
Also, there are no tests in this pull request, how we will know in the future that this feature will continue to work without it?
Some examples can be found in
integration_test.go
,TestRenderJsonAttributesMetadata
I've implemented a test close to the TestTerragruntOutputFromDependency
test. WDYT ?
Looks like CI build is failing:
Stderr: # github.com/gruntwork-io/terragrunt/cli
cli/cli_app.go:643:50: not enough arguments in call to configstack.FindStackInSubfolders
have (*options.TerragruntOptions)
want (*options.TerragruntOptions, *config.TerragruntConfig)
Looks like CI build is failing:
Stderr: # github.com/gruntwork-io/terragrunt/cli cli/cli_app.go:643:50: not enough arguments in call to configstack.FindStackInSubfolders have (*options.TerragruntOptions) want (*options.TerragruntOptions, *config.TerragruntConfig)
Fixed 🔨