So I'm a little new. Are Pulumi stacks able to be ...
# generalm
millions-beach-85282
02/06/2020, 6:56 PMSo I'm a little new. Are Pulumi stacks able to be paramaterized/dynamic?
For example I'd like to define a Pulmini stack for Pull Request sites/environments such that in my CI/CD pipelines I can have the PR trigger creation of an environment using Pulumi but passing in the PR branch name to isolate resources into their own domains and resource groups. Is this use case possible without static/generated YAML files for every PR site?
m
many-garden-84306
02/06/2020, 7:02 PMYou need a pulumi program for each project, and it needs to be configured and run for each stack in that project. But you can use the same project for multiple stacks, or you can use a single stack and generate all the resources in a for loop. Each time you run pulumi, if the resources you generate change, pulumi creates/destroys/updates infrastructure to match
many-garden-84306
02/06/2020, 7:05 PMSince pull requests have limited lifetime but there may be a lot of them, it seems safer to create a stack for each pull request branch (in a single pulumi project). then you can just destroy the stack after you have resolved the pull request, and pulumi will clean everything up. if anything goes wrong it won't affect the other stacks.
many-garden-84306
02/06/2020, 7:08 PMregardless of whether you use one stack or many, all the state for a stack is kept in the pulumi cloud service, so there is only one source file.
m
millions-beach-85282
02/06/2020, 9:30 PM@many-garden-84306 Thanks!
b
boundless-monkey-50243
02/07/2020, 8:47 PMFWIW, we use env vars for a number of things in our deploys, and those are separate from our config files (intentionally).
boundless-monkey-50243
02/07/2020, 8:49 PMi.e., for an ECS service, stuff like "what stack has the ECS cluster?" is parameterized via config.yaml. However, since we want our developers to be able to actually deploy stuff without a git push, CONTAINER_TAG is an env var that's injected by our CodeBuild (soon to be Jenkins) system.
Each env still retains a separate config file, though, and it definitely does cause friction in an env-per-branch world like you describe. It's possible to write a single Pulumi program that allows many app envs, and doing so would be a lot easier than the equivalent Terraform code, but it'd be a bit rough.