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.
important-leather-28796
03/18/2019, 6:58 PM
I’m open to other ideas, but in this case we are fully reproducible/redeployable with the version of code committed
o
orange-policeman-59119
03/18/2019, 6:58 PM
GitLab CI/CD is designed around immutable/idempotent pipelines (for better or worse), so the runner has a read-only token for pulling
i
important-leather-28796
03/18/2019, 7:00 PM
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.
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.