A helper function to run arbitrary commands #670
Conversation
bernardoVale
requested review from
autero1,
brikis98 and
eak12913
as code owners
README.md
Outdated
| `run_cmd(command, arg1, arg2...)` runs a shell command and returns the stdout as the result of the interpolation. | ||
|
|
||
| This is useful when you want to have a generic `terraform.tfvars` for all accounts and use a script to determine | ||
| information that changes from account to account, like the bucket name and the DynamoDB table: |
There was a problem hiding this comment.
I think this is more powerful than just that! It allows you to write scripts to dynamically fill in arbitrary information in your Terragrunt configuration.
There was a problem hiding this comment.
take a look now
| return "", errors.WithStackTrace(EmptyStringNotAllowed("parameter to the run_cmd function")) | ||
| } | ||
|
|
||
| currentPath := filepath.Dir(terragruntOptions.TerragruntConfigPath) |
There was a problem hiding this comment.
I think there's a terragruntOptions.WorkingDir
There was a problem hiding this comment.
The idea as that we run the command from the module folder because the command might need the path as the context. A good example (my actual use-case) is if you want to write a script that returns the bucket name based on the account (folder) where you are running the command.
Using the WorkingDir wouldn't work when you run *-all between accounts using --terragrunt-include-dir
There was a problem hiding this comment.
OK, fair enough. Please make sure to document that in the README!
config/config_helpers.go
Outdated
| Args: args, | ||
| Dir: currentPath, | ||
| } | ||
| stdout, err := command.Output() |
There was a problem hiding this comment.
Hm, we should probably both capture the output and stream it to console so users can see what happened when running their scripts... There's a function that does that already in Terragrunt: https://github.com/gruntwork-io/terragrunt/blob/master/shell/run_shell_cmd.go#L39
There was a problem hiding this comment.
We can't use this function since it currently forces us to use terragruntOptions.WorkingDir. There are two options:
A - We change the function to accept a custom workingDir.
B - We don't use it and just posts the stdout to the logs
I'm leaning towards B. I think that most use cases for run_cmd will be running small shell scripts that take less than a second to execute, so I think that streaming the logs is overkill, we can simply add the stdout to the logs once the function finishes its execution.
thoughts?
There was a problem hiding this comment.
I would vote for A. Should be a minor change and we improve the user experience.
I can see this feature being used by teams to run terragrunt output xxx in some other folder to get outputs from other modules. Having streaming logs for that sort of thing is quite handy.
Thanks!
There was a problem hiding this comment.
take a look now
|
Hm, got a test failure: Any idea what that is? |
|
weird this test is passing here. |
|
@brikis98 found the error. I forgot to add the emtpy |
|
check #673 |
Fix broken test introduced on PR #670
|
Is anything blocking a release? I could really make use of this new feature 👍 |
|
This is now released in https://github.com/gruntwork-io/terragrunt/releases/tag/v0.18.2! Thx @bernardoVale! |
In my use case, we'll have multiple
live-infrastructurerepos. One particular drawback of such implementation is that you can end up with a lack of pattern.To cope with that, I wanted to implement generic
terraform.tfvarsthat can be easily copy-pasted, everywhere and upgraded to a new version when needed. Since there's information that changes from account to account and repo per repo, like the bucket name and the dynamoDB table I plan to write a script that determines such information based on the path and the repo name.This PR provides this functionality with a simple helper function that runs any command with a list of arguments and returns the stdout as the result.