No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

<@UEEUJNR9B> 20 stacks in each environment? or distributed across environments?

I tried to this on EKS with Gitlab based on inputs from <@UDP6ZMQUE> and <@UH52500AG> -- here is an example of how we did it with <@UB27BHS4B> <https://blog.pulumi.com/continuous-delivery-with-gitlab-and-pulumi-on-amazon-eks?hs_preview=SkXhaYiT-9743102699>

restricting to this thread so not to spam others.

I read the blog post. How do you just deploy `dev` if there is a config change just for `dev`? The CI should skip deploying to other `env`

the CD tool needs to have a project defined with build triggers in the `dev` environment

you need to define a Gitlab pipeline for Dev, Stage and Prod

In each pipeline aka dev: you have stacks (say 7)

GitLab pipeline for dev is configured using `.gitlab-ci.yml` files in the root of each repository that has your related files

say your repository project is called `sample-iam`

then your `.gitlab-ci.yml` file will look like this

```image:
  name: pulumi/pulumi:v0.17.10
  entrypoint:
    - '/usr/bin/env'
    - 'PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'

stages:
  - preview
  - update
  - downstream

Pulumi Preview:
  stage: preview
  script:
    - npm ci
    - pulumi stack select pulumi/sample-iam/$DEPLOY_ENVIRONMENT
    - pulumi preview

Pulumi Update:
  stage: update
  script:
    - npm ci
    - pulumi stack select pulumi/sample-iam/$DEPLOY_ENVIRONMENT
    - pulumi update --skip-preview

Update EKS:
  stage: downstream
  trigger: pulumi-gitlab/sample-eks```

you define the stage "update" -- implies when there is an update as defined in this file, trigger stage "downstream" which is essentially the next project called `sample-eks` in environment:dev

so you can have 7 stacks in dev organized as separate projects -- each stack update, trigger a downstream stack in that `environment: dev`

I am not sure if you can trigger all 7 stacks simultaneously within 1 project as I have never tried that approach

taking a break -- but please read and let me know what other qs you have -- will come back and respond!