actions
actions copied to clipboard
Support for 'stack output' command
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.
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.
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.
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.
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?
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!
Looking at the likes it's not only our project that would benefit from this one :) The PR is still up for merge
+1 for being able to run command: output
to get current outputs without needing to run e.g. up
beforehand.
This was actually released in v5.1.0
Cannot close issue:
- does not have required labels:
resolution/
Please fix these problems and try again.
Cannot close issue:
- does not have an assignee
Please fix these problems and try again.
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 foundat 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
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.
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 thestack
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 usinginlineSourceStackHelper
as it's done forcreateStack
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.
Sounds like this should re-open to track that it's not yet usable.
Any updates here? would love to switch to pulumi output
instead of pulumi preview