This message was deleted.

Pulumi is just spinning up the infrastructure. I would definitely keep that in a separate repo. Your application should define how it should be deployed (kubernetes manifests) and should not be concerned about Pulumi code

If you're using Github Actions, you could use workflow_dispatch or workflow_call for cross-repo workflows. Other providers will likely have an equivalent. I found having a separate Stack just for the application definitions (ie, task definition in ECS, or Deployment in k8s) useful; keeps it speedy, and less area of effect. We're doing image build/push in a separate process, so query for the image digest based on tags in the stack. Lucky you, ECR has it built in for you in pulumi. Finally, there's nothing stopping you from having a small stack in the application repo, and using Stack References to query details about your core infrastructure (exposed in the stacks in your separate repo).

I was following this example https://github.com/pulumi/examples/blob/master/aws-ts-hello-fargate/index.ts They have the application code and pulumi code in the same project. Is it as simple as omitting steps 3 - 5 from the pulumi repo and executing those steps on the application repo through ci/cd?

Pretty much, though I'm not familiar with Crosswalk or the recommendations of how to use it

Hey @brief-vase-28416, I recently wrote an article that covers how I split up application and infrastructure deployments, and I use AWS ECS Fargate in my example. Short answer is that I have a base stack and an app stack. The base stack is VPC, RDS, ALB, etc. and the app stack is ECS resources: cluster, task definitions and services. When I initially deploy the app stack I just use the latest tag, then I have a separate GitHub actions script that registers a new task definition and updates the services with that task def https://briancaffey.github.io/2022/06/26/i-deployed-the-same-containerized-serverless-django-application-with-aws-cdk-and-terraform

@important-australia-24045 thanks for sharing, super detailed and relevant to my setup. I ended up going for a similar concept, an infra repo with an infra stack (no task definitions), and an app repo with application code and an app stack (creates Fargate service with new task definition) I haven’t reached creating on-demand review environments yet but will definitely check out your article when I do