Skip to content

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.

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.

  • 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.

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.