This message was deleted.
# general
s
This message was deleted.
b
do you mean that you are unit testing the other stacks? because if so you should be able to mock it without spinning it up
b
No they're integration(examples) style tests
b
ok so what do you mean when you ask "what is the best way"? Do you have concerns with just spinning it up?
b
I figured I can't be the only one with layers of stacks where a previous layer is needed to build the next layer and test it.
So I was looking for a more canonical way of doing it instead of trying to invent my own...
I could rig something up in the Makefile if there's no other way.
I played with integration.ProgramTestManualLifeCycle but it doesn't provide access to the stack outputs.
b
I'm not sure what
integration.ProgramTestManualLifeCycle
is - is that a pulumi SDK thing or is that related to the CI/CD you are using? I didn't find it in the pulumi repo. Anyways I don't think Pulumi will have a canonical answer regarding this for you.. I would wager it is largely up to you. Personally I would keep a "CI/CD" related stack of the network project up and running so the pipelines for my child projects could test against it while remaining isolated to running the child project code. But I'd guess that could add up if you have many nested stack dependencies
b
oh sweet. Sorry I use the .NET SDK and I'm not sure something like that exists. It looks like it lets you execute pulumi commands though, could you use that to get your stack output via
pulumi stack output
?
w
Pulumi’s automation API can be used to orchestrate stacks: https://www.pulumi.com/docs/guides/automation-api/ This would allow you can sequence the stacks as you need to.