Am I understanding correctly that Review Stacks ar...
# pulumi-deployments
Am I understanding correctly that Review Stacks are designed to be more flexible (at scale) than GitLab CI Dynamic Environments? Trying to sort out how I might rewrite our MR-based staging dynamic environment setup in GitLab to use Pulumi Deployments instead. Ideas I came to so far are: • I could dynamically test the infra, in addition to just the k8s app. Today, I bootstrap a new TF'd rancher stack by hand, then set up core services also by hand i.e.: git clone + k8s apply (e.g.: cluster-wide ingress controller), then I need to point the MR dynamic env to this new stack by hand. So to avoid all this, I usually just spin up a MR-based app-only environment directly in the production cluster under a new k8s namespace, to keep it isolated; this has it's pros and cons :-)) • I could use the pulumi REST api to spin up a pr-based environment (for infra, core, and app) in one go, I'll need to rewrite my 3 layers as 3 different interdependent pulumi stacks though, as per ideas here: Any other examples I could reference, to size up the amount of work required? I also saw: which I play-tested and works ok as is. Though this approach ties me to git-only actions to trigger deployments. What I like is the visibility provided right inside gitlab, whereas with Pulumi Deployments, I'd have to travel to to see what's going on(?)
Yes, review stacks are designed to be substantially more flexible. The deployments REST API the review stacks is built ontop of is quite flexbile and powerful, enabling you to build your own custom workflow. Review stacks aren't currently supported for GitLab, but you can still use the REST API to trigger deployments using standard git credentials as you mention. We will eventually build deep GitLab support including review stacks and push to deploy. Feel free to give this issue a 👍 to follow along;