No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

I plan to do the same thing, but our ci process is changing/committing code in the build/test phase:
- build/tag images with commit sha
- test (assume success here)
- git flow start release xxx
- bump version numbers in manifests
- `pulumi config set version xxx`
- retag gcr images from sha with xxx
- git flow finish release xxx (pushes code to github)


Then we have a different ci job running on merges to `master`
- `pulumi up -y`

or at least that is the plan at this point.

I’m open to other ideas, but in this case we are fully reproducible/redeployable with the version of code committed

GitLab CI/CD is designed around immutable/idempotent pipelines (for better or worse), so the runner has a read-only token for pulling

We focused on auto-release and did it with circleci, git-flow, and some custom scripts.  All this is definitely dependent on choices you make for your toolchain.