actions icon indicating copy to clipboard operation
actions copied to clipboard

Support for 'stack output' command

Open mikocot opened this issue 2 years ago • 15 comments

Hello!

  • Vote on this issue by adding a 👍 reaction
  • If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

  • Add output command support to actions

There are multiple scenarios where it's useful to fetch outputs from a stack without having to first call preview or up.. Reading outputs is fast and has no side effects. while lets you access stack configuration that may not be available anywhere else.

For now we are running pulumi stack output as bash code in our pipeline, but this is ugly and hard to maintain. It's also especially annoying as the whole logic to pass outputs and secrets into github workflow is already there and triggered as part of calling up/preview/refresh/.... All it takes is to allow that same logic by itself.

Affected area/feature

I have looked into solving it myself and it looks like a very subtle change. Please see: support for stack output

Yet, for some reason the outputs don't seem to be rendered and I don't really have the test environment and sufficient understanding of underlying system to investigate it. I guess some preconditions might need to be met before stack.outputs() is called or some configuration needs to be adapted.

mikocot avatar Feb 16 '23 10:02 mikocot

This seems a reasonable request. I'm a little hesitant about the action just becoming a shim over everything the CLI does, and this is another small tick towards that, but I think this still has justification.

You linked commit looks reasonable, I'm surprised it didn't just work. I think we can probably take that pretty much as is and go work out what little bits missing to make it work.

Frassle avatar Feb 16 '23 14:02 Frassle

TBH I dont see much wrong about the action becoming a wrapper for the CLI =D Since it only runs the command behind the scenes it feels there is not much duplication and maintenance needed. Anyway, this particular command surely has a value for CI/CD.

As for the implementation, maybe it's just me testing it incorrectly. I'll make a PR and you can check it yourself.

mikocot avatar Feb 16 '23 15:02 mikocot

I'm playing a bit with Pulumi and Kubernetes with github actions and I just this issue

It would be great to have this, because in my case, if nothing has changed in my pulumi folder I skip the pulumi job.

Being able to access pulumi secrets / outputs in other jobs without a preview or up would be great.

juchom avatar Feb 20 '23 17:02 juchom

we've just found some more scenarios where we need to construct a pretty ugly and error pron bash script to get the outputs, while this feature seems to be quite close to finishing with my PR, any chances we'll see it merged soon?

mikocot avatar Apr 06 '23 10:04 mikocot

Hi Mikocot, Sorry, I haven't had an opportunity to revisit some of the PRs on this repo just yet. I'm going to try to make some time next week. Apologies for the slow reply!

RobbieMcKinstry avatar Apr 07 '23 15:04 RobbieMcKinstry

Looking at the likes it's not only our project that would benefit from this one :) The PR is still up for merge

mikocot avatar Oct 09 '23 08:10 mikocot

+1 for being able to run command: output to get current outputs without needing to run e.g. up beforehand.

ghferrari avatar Jan 30 '24 18:01 ghferrari

This was actually released in v5.1.0

Frassle avatar Jan 30 '24 21:01 Frassle

Cannot close issue:

  • does not have required labels: resolution/

Please fix these problems and try again.

pulumi-bot avatar Jan 30 '24 21:01 pulumi-bot

Cannot close issue:

  • does not have an assignee

Please fix these problems and try again.

pulumi-bot avatar Jan 30 '24 21:01 pulumi-bot

Actually there is an issue with this implementation, which I believe was not a problem in our CI/CD back when I did the initial PR. But it is now, when it became more complex with jobs being more isolated and have no access to the original code.

As this action reuses logic for the other commands (up/preview...) it runs first the stack select, which contrary to simple 'outputs' run requires pulumi config to be present.

So when we replaced the original workaround:

LOCAL_VARIABLE=$(pulumi stack output SOME_OUTPUT_FIELD--stack "${{ inputs.stack-name }}" --non-interactive)
echo "LOCAL_VARIABLE=$loginSrv" >> "$GITHUB_OUTPUT"

to:

uses: pulumi/actions@v5
       with:
         command: output
         stack-name: ${{ inputs.stack-name }}

It fails with:

err?: Error: Command failed with exit code 255: pulumi stack select --stack [EDITED_ORG]/[EDITED_STACK_NAME]/pr-811 --non-interactive error: no Pulumi.yaml project file found (searching upwards from /home/runner/work/[PROJ_DIR]/[PROJ_NAME]). If you have not created a project yet, use pulumi new to do so: no project file found

at Object.createCommandError (/home/runner/work/_actions/pulumi/actions/v5/webpack:/pulumi-github-action/node_modules/@pulumi/pulumi/automation/errors.js:77:1)
at Object.<anonymous> (/home/runner/work/_actions/pulumi/actions/v5/webpack:/pulumi-github-action/node_modules/@pulumi/pulumi/automation/cmd.js:76:1)
at Generator.throw (<anonymous>)
at rejected (/home/runner/work/_actions/pulumi/actions/v5/webpack:/pulumi-github-action/node_modules/@pulumi/pulumi/automation/cmd.js:19:1)
at processTicksAndRejections (node:internal/process/task_queues:95:5)

the same behavior is visible with CLI: pulumi stack select --stack "${{ inputs.stack-name }}" --non-interactive requires config, but output doesn't (understandable). Ideally the action would just do: pulumi stack output SOME_OUTPUT_FIELD--stack "${{ inputs.stack-name }}" --non-interactive

mikocot avatar Feb 06 '24 10:02 mikocot

For me, the output command simply doesn't work (using v5.5.1). If I use command: output then no outputs are available via the GitHub actions steps.<step_id>.outputs method. But if I use e.g. command: up, then the outputs are available.

ghferrari avatar Feb 06 '24 10:02 ghferrari

From a quick look it needs a bit of a rewrite, I think it wasn't properly tested before merging my draft. How I see it done to be correct:

  • divide main.ts's runAction into two flows, one that uses LocalWorkspace to create/select stack and runs basically all current commands besides 'outputs'. The other one that only runs a CLI command without any additional local setup and therefore without referencing the stack object.
  • In that second flow, we run stackOutputs methods from the LocalWorkspace (pulumi automation), which is just a wrapper on CLI, and which is the method run currently by the stack itself (passing only its name)
  • [modify pulumi/automation] The missing part is that the stackOutputs method is not a static one, and needs a LocalWorkspace instance. But this can be easily avoided using inlineSourceStackHelper as it's done for createStack for example. We'd just need a static wrapper for it.

So long story short, create inline LocalWorkspace (as you do for createStack), use that workspace to run CLI's pulumi stack outputs, parse the outputs the same way it's done currently.

mikocot avatar Feb 06 '24 11:02 mikocot

Sounds like this should re-open to track that it's not yet usable.

Frassle avatar Feb 06 '24 11:02 Frassle

Any updates here? would love to switch to pulumi output instead of pulumi preview

darena-patrick avatar Mar 11 '24 20:03 darena-patrick