feat: Add option to omit stdout from the action's outputs

[ionicsolutions]

Adds an option to exclude the captured stdout in the action's output.

This can be useful when using the action's output to populate the environment of subsequent workflow steps by setting env: ${{ steps.pulumi.outputs }} or jointly exporting the stack outputs to other steps and jobs via toJSON(steps.pulumi.outputs), where they can then be retrieved as, e.g., env: ${{ fromJSON(needs.pulumi.outputs.stack-outputs) }}.

[iwahbe]

Hi @ionicsolutions. Thanks for opening a PR and I'm sorry it took so long to get reviewed. I'm not sure if adding an option to suppress stdout from outputs is the best solution here. I'll have a chat with my team and get back to you by EOW.

[ionicsolutions]

Hi @ionicsolutions. Thanks for opening a PR and I'm sorry it took so long to get reviewed. I'm not sure if adding an option to suppress stdout from outputs is the best solution here. I'll have a chat with my team and get back to you by EOW.

Thanks for the update!

The main issue with including stdout in the "outputs" is that it makes it very large even for modestly sized stacks, making env: ${{ steps.pulumi.outputs }} unusable in practice because you need to scroll through tons of log output when inspecting job/step inputs.

If you do not want to add an option suppressing the stdout, an alternative solution would be to add an option that moves the stack outputs to a single key (perhaps already encoded as JSON, similar to the CLI's --json).

The goal is to be able to access just the outputs, without knowing their names ahead of time, so that the Pulumi Action can be wrapped into a reusable workflow or custom Action that's used for a range of different programs.

I've never had the need to access the captured stdout in subsequent steps, so I might be overlooking use cases where having both the stdout and the universal output access is helpful. From my point of view and the way I've used the Action, this output could be omitted entirely.

[iwahbe]

We would like to add a new top level output key: stack-outputs, as you suggested in your original PR description. To preserve backward compatibility, each stack output would be set at both the top level and nested inside stack-outputs.

Would you be willing to update your PR?

[ionicsolutions]

We would like to add a new top level output key: stack-outputs, as you suggested in your original PR description. To preserve backward compatibility, each stack output would be set at both the top level and nested inside stack-outputs.

I can look into this, but it's not a high priority for me right now.