Publish failed
The publish stage runs after cdk deploy succeeds and after OIDC + bootstrap are confirmed. It moves your application artifacts into the AWS resources the deployment created:
- S3 — a website bucket for static-site frontends
Container apps don’t have a publish stage in current setups: the deploy stage pushes the image and rolls out the service, so those failures are covered in Deploy failed. Setups generated before that change still push to ECR and roll out ECS in a publish job; the table below covers them too.
A publish failure is almost always one of three shapes. The GitHub job log names which one.
Find the failing step
Section titled “Find the failing step”Open the failed publish job in the GitHub Actions run and read the step around the failure:
| Symptom in the log | What it is |
|---|---|
AWS CLI / s3 error mentioning a bucket (for example bucket not found, NoSuchBucket, AccessDenied) |
S3 sync to the website bucket failed — region, bucket name, or permission mismatch |
docker push / ECR / denied / unauthorized |
ECR push failed — the repository is missing, the role cannot ecr:*, or the image tag is malformed |
ecs:UpdateService / RegisterTaskDefinition / DescribeServices error |
ECS rollout failed — a task definition register failed, or the service update was rejected |
403/AccessDenied across any of the above |
OIDC deploy role lacks a permission the publish action needs |
You do not need to re-run the deploy step — bootstrap and cdk deploy already completed. Re-running the publish step (or the whole workflow) after you fix the cause re-applies only publish.
Common fixes
Section titled “Common fixes”- Wrong region or bucket. Confirm the AWS region in the workflow matches the region you deployed into. A mismatch between the deploy region and the publish target is a frequent cause of “bucket/service not found in this region.”
- Role permissions. The generated OIDC deploy role grants S3/ECR/ECS for the resources it manages. If publish fails with an IAM reason, re-check that the deploy role is the one the workflow assumes for this account and region (not an older role from a previous setup).
- Image tag/manifest. For container backends, an image push failure is almost always a tag issue or a missing repository. Confirm the repository exists in the region and that the push uses the repository it created.
Fix and retry
Section titled “Fix and retry”After you correct the cause, run the deploy workflow again from ScaleBop’s Pipeline page or from GitHub Actions. Publish then re-pushes artifacts against the already-deployed infrastructure and finishes the attempt.
If publish succeeds but the health-check stage then fails, the cause is upstream of publish in the pipeline — continue to Health check failed.