Take deployment environment into account when deciding what is affected

[MxKaras]

Our problem:

We have three environments in Github: dev, staging, and production. Our flow is that we deploy feature branches to dev, and when it is merged deploy to staging and then production. These latter two are both deploying main.

We are using this action with last-successful-event: deployment.

Right now npx nx affected -t deploy gives the following outcomes:

• dev: incremental deploy as expected ✅
• staging: incremental deploy as expected ✅
• production: nothing is deployed as there is already a successful deployment to main ❌

Proposed Solution:

Change the action to accept an optional deployment-environment that will be used when last-successful-event is deployment to differentiate between deployments to different environments.

[fvalmeida]

Hey, maintainers, do you have any recommendations on how to deal with this situation? There have been no comments so far, so I'm not sure if this is considered a problem to be addressed.

[meeroslav]

Hi @MxKaras and @fvalmeida,

Sorry for the delay. I'm not sure I fully understand your problem.
From my understanding the flow should be the following:

- Run `nx-set-shas` on `main` to find `BASE` and `HEAD` SHAs
- Running `nx affected -t deploy` on both `staging` and `production`

If these are running on a separate workflow, I would run the nx-set-shas in a separate job and then pass the BASE and HEAD as input to the other two jobs/workflows.

Does that make sense? If not, can you provide more detailed example?

[MxKaras]

Hi @meeroslav , thanks for the reply. I'll expand on our flow. A merge to main triggers a series of automated steps:

• Merge PR to main
• create deployment to GH environment staging
• trigger build & deploy workflow
  • nx-set-shas with last-successful-event: deployment
  • nx affected -t deploy
  • mark deployment success

Separately, we have a manually run action that creates a deployment to GH environment production, kicking off another build & deploy workflow with the same steps. This is typically run after staging has completed, but it in theory can be used to deploy any ref to any env.

Assuming that the production workflow runs after the staging one has completed successfully, running nx-set-shas will return HEAD == BASE because a successful deployment has already been made to main during the staging deployment.

If it was possible to not only find the commit for the last successful deployment, but the commit for the last successful deployment to a specified environment, that would be very useful. Right now we are deploying all services in production for every change.

Running nx-set-shas separately and caching HEAD/BASE or whatever would be technically possible but I don't want to play around with that if the tool can do the work for me. I could probably raise a PR mysef, but I haven't got around to doing so yet in almost a year so who knows if I'd ever get round to it 😅

[JamesHenry]

@MxKaras Taking a quick look at https://docs.github.com/en/rest/actions/workflow-runs?apiVersion=2022-11-28 it looks like there isn't any parameter we can use to filter environments directly, but we could filter based on the "environments" data once the response is returned.

It would be great if you could fork the repo and use the action from your fork, apply the new configuration option to ensure it works for your use-case and then create a pull request back to this repo.

Is that something you are open to trying?