Open mikocot opened 1 year ago
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.
Cannot close issue:
resolution/
Please fix these problems and try again.
Cannot close issue:
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:
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.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)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.
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
I saw version 6 was available. Is there any chance for adding this support soon?
Hello!
Issue details
output
command support to actionsThere are multiple scenarios where it's useful to fetch outputs from a stack without having to first call
preview
orup
.. 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 callingup
/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.