This message was deleted.
# general
s
This message was deleted.
d
The article links to the repo for code examples: https://github.com/pulumi-zephyr/zephyr-app/tree/blog/inner-dev-loop Though the relavant part is nested in this directory: https://github.com/pulumi-zephyr/zephyr-app/tree/blog/inner-dev-loop/develop/pulumi
There's some details here about using a different state provider, such as a local file system or s3 bucket instead of pulumi cloud. https://www.pulumi.com/docs/concepts/state/#using-a-self-managed-backend
p
So is it so that the example code is able to run
pulumi up
without a stack just because it’s using @pulumi/docker? That’s the part that I found confusing about the setup of the code there.
d
They're still using stacks. They have another linked article around per-user stacks: https://www.pulumi.com/blog/iac-recommended-practices-developer-stacks-git-branches/
p
Thanks for taking your time to help me out. One last thing about https://github.com/pulumi-zephyr/zephyr-app/tree/blog/inner-dev-loop/develop/pulumi is that it doesn’t contain any stack files. I guess, because this is not mentioned in the article about local testing, that implies that a stack is created for the user, and then removed after the testing is done? Is that the right conclusion here?
d
Yes, it looks like the user creates their own stack with this command:
pulumi stack init zephyr/developer-name --copy-config-from zephyr/dev
The
dev
stack will be stored in pulumi cloud, which means someone has done
pulumi up -s zephyr/dev
at some point. The stack file doesn't necessarily need to be stored alongside the code.
🙏 1
p
Thank you again! This clears up quite a few things. Have a lovely day there 🙂
s
You can also just run
pulumi stack init <name>
in the directory with the local testing code, to create your own stack (and that stack could be on Pulumi Cloud or on a self-managed backend). Using
--copy-config-from zephyr/dev
won’t work for you because you don’t have access to the “zephyr” organization on Pulumi Cloud. 🙂
🙏 1
p
I’m mostly trying to figure out a setup for local development + api testing in CI/CD without deploying any real resources (for now). We depend on SSM secrets, SQS, and RDS mostly. I’m considering to just write a small wrapper script that inits the user stack based on a shared config, and then destroys it once the tests are done, or the user wants to stop developing (stop
serve
).