Github Action avoid approval on same environment rule within same workflow

Question

Reusing same environment rule within same workflow

Running our workflow in Github, we split our tasks up into 2 jobs; Building docker image & attach tags and deploying to AWS using CodeDeploy. The reason for splitting the tasks up is to avoid creating new tags whenever our deployment fails.

However... using environment protection rules creates a roadblock as every job needs to be approved(even though we already ran the same environment previously)

The deployment job is a conditional job, meaning it depends on the success of the Build job.

Is there any way to get around this?

Github workflow

Helicoid

Do both of the jobs require the environment e.g. for getting the attached secrets? Or could you drop the environment from one of the jobs? An option could be to have two environments with differing rules, but that would add overhead if they have the same secret requirements. – Bylaw

Both are using the same environment secrets, so removing them would not work in this case. Idd an option would be to, create two environments, but that creates repetitive errors. – Helicoid

@Helicoid any updates about your issue ? – Inspirit

@RomainG we started out with the workaround with two identical environments(one protected and one not) and then worked on reducing the jobs to avoid the issue. – Helicoid

Answer 1

I'm not sure I have the full context here but based on the above screenshot here would be my recommendation.

1. Update the workflow to build and push the container image once. Ideally, you want to build once and deploy many anyway to ensure your container is the same across each environment.
2. Update the workflow to do a sequential deployment -- dev -> pre-prod -> prod by adding a needs block for each environment.
3. Add a unique GitHub environment for each deployment job which will have their own protection rules. Or maybe you don't care about approving deployments to the dev environment -- so just don't add an environment rule for that deployment environment.

Hopefully this helps provide some guidance.

Noriega

Answer 2

Having the same issue as you. We have a deployment where we want to ensure that the bicep infrastructure job is done verifying+setting up any misconfigured resources in Azure before deploying our code. This job requires the same env as the code deployment itself. Having the needs: deploy_infra will trigger a new approval request for the resources depending on the infrastructure step. I would prefer for environment approval requests to only be triggered once per workflow, but until then we decided to remove the needs: deploy_infra on the code-deployment.

It seems like it is possible to only get one approval per workflow (even if multiple jobs) as long as the jobs don't depend on each other.

Mafia

Answer 3

I have a similar but reverse dependency issue. I would like to have an approval on the deployment of the "foo" environment and still need the "foo" environment for the build job that I dont want to have an approval. This is one of the challenges where CircleCI did a better job by not coupling approvals with environments.

For me workflow has jobs 1(build) and 2(deploy) which both need environment foo for image build/deploy. I dont want to require a build approval. Thats silly, but I also dont want to duplicate environment variables.

This was a suggested workaround but it is rather ugly in my opinion. It is a job that auto approves https://github.com/orgs/community/discussions/27600

Steinmetz