https://pulumi.com
Join Slack
This message was deleted.
# general
s
This message was deleted.
w
To be clear, at the moment I have the build of container image as a build script, but I would like to use pulumi for that as well since then I could just reference another stack to get a reference to the container registry instead of hard coding it.
What I would like to have is one project that does both the docker image creation and publish, but also can deploy to kubernetes. What gets done should be based on input parameters. Using 
-c
seems wrong since that modifies the yaml file. I can probably have a workaround where I set an environment variable before running 
pulumi up
and then use that to control what gets done, but that seems wrong as well. Maybe I do need two separate projects for it if I want to trigger it differently?
l
Sounds like two projects, or maybe more. But you can use multiple providers in a single project if you want to make it work. Personally I go the other way: lots of projects for one "set" of infrastructure, giving me finer-grain control over what to deploy and when.
StackReferences link them together easily.
w
got it. So basically what you suggest is: * Project (s) for general infrastructure * Per app have - One project for creating the image - One project for deploying I can live with that, I just want to know what is recommended 🙂. I already have the deploy project linking back to the infra project one, so I'll just create one more project.
Open in Slack
PreviousNext
Powered by

Pulumi Community

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.

Powered by