Conversation
|
Why not just use |
|
Because I don't want all the env vars. This allows only printing the actual ssm parameters. This is running between circle jobs, and there could be other env vars in scope that we don't necessarily want to persist across jobs. |
|
And this seemed like a reasonable feature to support, vs. trying to do some mix of printenv and grep, xargs, etc. to achieve a similar result. |
Add a -print flag which accepts no additional arguments and prints any
found SSM env vars to stdout instead of exec-ing a process with the env
vars set.
```sh
-print
Print the decrypted env vars without exporting them and exit
```
The use-case for this is in places like CI jobs where you may want to
resolve SSM parameters and then write them to a config file, or persist
them elsewhere for subsequent use.
ssm-env is already a bit architecturally overloaded, and this strains it
further. I'm not inclined to do a major refactor/rewrite at this point,
but if we want to continue extending it that may be required at some
point. I'd prob start by separating the interfaces for outputs and
fallibility to avoid overloading the expandEnviron/setEnviron functions
the way they currently are.
Maybe more of a discussion for that use case than the feature here, but I'm concerned that conflating "vars that are substituted by ssm-env" and "vars that need to be persisted in CI" might create confusion later; e.g. it's not clear from just the CI config which vars would be persisted, and it wouldn't be clear how to exclude ssm vars or include non-ssm vars. Have you considered using a script with an explicit list of vars? |
2 participants
Add a -print flag which accepts no additional arguments and prints any found SSM env vars to stdout instead of exec-ing a process with the env vars set.
-print Print the decrypted env vars without exporting them and exitThe use-case for this is in places like CI jobs where you may want to resolve SSM parameters and then write them to a config file, or persist them elsewhere for subsequent use.
ssm-env is already a bit architecturally overloaded, and this strains it further. I'm not inclined to do a major refactor/rewrite at this point, but if we want to continue extending it that may be required at some point. I'd prob start by separating the interfaces for outputs and fallibility to avoid overloading the expandEnviron/setEnviron functions the way they currently are.