GitHub actions related questions: I am curious to know if other folks here are using

pulumi up

on merge to main as described here: https://www.pulumi.com/docs/iac/using-pulumi/continuous-delivery/github-actions/#the-push-workflow-file or something else? I like the idea and have tested it several times but in case of errors during the up operation I end up creating a dummy PR to trigger a

pulumi preview

and then merge to run

pulumi up

again, in order to fix the previous operation. What is your workflow overall to apply infra as code on your cloud provider of choice?

Since mistakes happen and manual fixes are inevitable, we have to have a manual way of running all commands. For some stacks this is a manually-triggered workflow, but mostly it's just a manual invocation of

pulumi up

.

We use GitHub actions for all deployments. What we've done is just enforce a specific order of environments, i.e. dev -> test -> prod. We encourage our developers to try and fail so they can learn, so by making sure a successful deployment to dev has been made before a PR is merged, we're fine. Our dev system is not required to be stable, so if a service goes down it's not a problem

@little-cartoon-10569 thanks.

For some stacks this is a manually-triggered workflow

I've gone that route too and added a

workflow_dispatch:

option to invoke

pulumi up

@kind-motherboard-59197 thanks.

by making sure a successful deployment to dev has been made before a PR is merged

Does that mean you trigger an action whenever a branch is created that aims to deploy to dev, then if that action succeeds, you unlock merging to main which in then deploys the same change to prod?

Each team do things a little different, but the usual approach is that whenever a PR is created, it starts a workflow. We've created GitHub environments that have assigned reviewers to them and a deploy approval is required. That way, someone will have to manually accept the deployment so nothing is deployed accidentally if you've pushed something that's incomplete.

Ah I see thanks. I've not started using environments yet but we'll most likely end up setting them up too.

There are many ways of doing this obviously but usually I would add a separate job in the deployment workflow. Personally I just think it's more explicit and easier to understand. Because we have required reviewers on our github environments, a

pulumi preview

job for our dev environment would require reviewers to approve the deployment in the exact same way as if it was

pulumi up

Thanks much appreciated! Yes I forgot to mention that I was already using 2 workflows, one for preview and another one to apply the changes, but I'm definitely missing a

workflow_dispatch

for preview (as it would indeed be convenient to trigger it on demand, rather than using a label).