Bug
In release-deploy.yml, the deploy-to-prod job passes the wrong cluster name to deploy-ecs-service:
# line 142 — should be cluster_name_prod
CLUSTER_NAME: ${{ inputs.cluster_name_staging }}
CLUSTER_NAME is used by the aws ecs update-service --force-new-deployment and aws ecs wait services-stable steps inside deploy-ecs-service. Because FORCE_NEW_DEPLOYMENT defaults to false and is not passed in release-deploy.yml, these steps are currently skipped — so the bug is latent today. However, enabling FORCE_NEW_DEPLOYMENT on a release deployment would issue the force-new-deployment call against the staging cluster instead of prod.
Fix
Change line 142 from:
CLUSTER_NAME: ${{ inputs.cluster_name_staging }}
to:
CLUSTER_NAME: ${{ inputs.cluster_name_prod }}
A PR with this fix is open: https://github.com/aproorg/github-workflows/pull/$(gh pr create --repo aproorg/github-workflows --head mawbid:fix/prod-cluster-name --base main --title "fix: pass cluster_name_prod to deploy-to-prod job" --body "$(cat <<'PRBODY'
Fixes the deploy-to-prod job in release-deploy.yml which was passing cluster_name_staging as CLUSTER_NAME instead of cluster_name_prod.
CLUSTER_NAME is only used by the force-new-deployment and wait services-stable steps in deploy-ecs-service, and those steps are currently skipped because FORCE_NEW_DEPLOYMENT defaults to false. The bug is therefore latent — but enabling FORCE_NEW_DEPLOYMENT on a release deploy would target the staging cluster instead of prod.
One-line change: cluster_name_staging → cluster_name_prod on the CLUSTER_NAME input of the prod deployment step.
PRBODY
)" 2>&1 | grep -o '[0-9]*$')
Bug
In
release-deploy.yml, thedeploy-to-prodjob passes the wrong cluster name todeploy-ecs-service:CLUSTER_NAMEis used by theaws ecs update-service --force-new-deploymentandaws ecs wait services-stablesteps insidedeploy-ecs-service. BecauseFORCE_NEW_DEPLOYMENTdefaults tofalseand is not passed inrelease-deploy.yml, these steps are currently skipped — so the bug is latent today. However, enablingFORCE_NEW_DEPLOYMENTon a release deployment would issue the force-new-deployment call against the staging cluster instead of prod.Fix
Change line 142 from:
to:
A PR with this fix is open: https://github.com/aproorg/github-workflows/pull/$(gh pr create --repo aproorg/github-workflows --head mawbid:fix/prod-cluster-name --base main --title "fix: pass cluster_name_prod to deploy-to-prod job" --body "$(cat <<'PRBODY'
Fixes the
deploy-to-prodjob inrelease-deploy.ymlwhich was passingcluster_name_stagingasCLUSTER_NAMEinstead ofcluster_name_prod.CLUSTER_NAMEis only used by theforce-new-deploymentandwait services-stablesteps indeploy-ecs-service, and those steps are currently skipped becauseFORCE_NEW_DEPLOYMENTdefaults tofalse. The bug is therefore latent — but enablingFORCE_NEW_DEPLOYMENTon a release deploy would target the staging cluster instead of prod.One-line change:
cluster_name_staging→cluster_name_prodon theCLUSTER_NAMEinput of the prod deployment step.PRBODY
)" 2>&1 | grep -o '[0-9]*$')