This message was deleted.

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

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.

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/

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?

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.

Thank you again! This clears up quite a few things. Have a lovely day there 🙂

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. 🙂

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

).