Stack outputs in stack groups hide the stack names about sceptre HOT 5 CLOSED

For anyone who wants a workaround to get this info in the meantime, this shell script does the trick:

#!/usr/bin/env bash
awk '/:/ {print $2}' | while read -r stack_name ; do
  aws cloudformation describe-stacks --stack-name "$stack_name" | jq -r --arg stack_name "$stack_name" '
    .Stacks[].Outputs[] | "!stack_output_external \($stack_name)::\(.OutputKey) [\(.OutputValue)]"
  '
done

Save that as /usr/local/bin/stackoutputs.sh and chmod +x it and then:

% sceptre list stacks | stackoutputs.sh

from sceptre.

A few reactions I have to this:

First, your example is slightly wrong. I don't know if that makes a difference for you or not.

sceptre --output=yaml list outputs

Technically, this command (like almost every other Sceptre command) takes a command path.

Second... I don't really understand what the purpose of listing out the envvars is in the first place. I never use environment variables with Sceptre because it means you need those environment variables set for EVERY action you take with Sceptre, so it gets pretty unsustainable very fast. I tend to prefer var-files. I don't see where we're even reading those in. Is this command some sort of relic of a former iteration of Sceptre that read these in? Or are they used now and I don't know? Looking at the docs, perhaps the only utility is the ability to dump the stack outputs in a CI/CD situation so they can be referenced in some other tooling/scripting.

Finally, what is the benefit of outputting them in the format of !stack_output_external nonprod-direct-connect::VPGWId --- vgw-1fb1e1e1af11da111? I don't see how that's an easy-to-interact-with format.

from sceptre.

Also, your example of VpcId: '!stack_output_external my-network-stack::VpcId' confuses me. If you quote resolvers, they're just strings, not valid resolvers.

from sceptre.

@jfalkenstein

1. Yes I just abbreviated the long command line. I thought it would be clear what I meant but you're right.
2. I agree. I don't think the export=envvar has any use, and neither does the default behaviour. The whole command is indeed broken, looks unloved, and makes the whole project look like it is unmaintained and unsupported!
3. The benefit of the output format proposed is this is exactly what people who use !stack_output_external to consume outputs will need to paste into their var files. And (updated) the same goes for the !stack_output output format that can be consumed by those who use !stack_output.

from sceptre.

Re your number 2, I do see a use for "envvar", in cases where CI/CD tools might do something like:

sceptre launch my/rds/stack.yaml
eval "sceptre list outputs --export=envvar my/rds/stack.yaml"
migration_tool run-my-migrations --connection-string $SCEPTRE_MyConnectionStringOutput

In other words, I can see the utility. I think you'd need to "read between the lines" of the documentation to accomplish that, though. I've thought for quite a while that a "Sceptre Recipe Book" might be a useful addition to our docs, since there are a lot of patterns that are possible but aren't really documented. They're basically left up to the creative engineer to implement them. You've got some crazy-complex and powerful Jinja patterns. I know my own project structure is often surprising to people when I tell them about it.

Regarding copying and pasting stack output references into var-files... that only actually works with your fancy "unquote resolvers" resolver... which isn't even a part of Core Sceptre. With that said, adding an additional export mode isn't such a big deal to me and I wouldn't actually mind that so long as it doesn't really change any existing functionality.

With all that said, here are my thoughts on the actual implementation:

• I think you might want to have two new export types:
  • external-stack-output would output the external stack output strings as you have proposed for use with !stack_output_external
  • stack-output would output the stack output strings for !stack_output
• I'm not as crazy about outputting the actual values for each output. Remember, they're not always as clean as a vpc id. They could be super long, multi-line strings or even json blobs. It could get ugly. I also don't know why you'd necessarily need the values for these new export modes.

from sceptre.