Skip to content

fix(release): recover image publishing for already-published releases - #117

Merged
sahenjp merged 1 commit into
mainfrom
fix/release-pipeline-recovery
Nov 6, 2026
Merged

sahenjp merged 1 commit into
mainfrom
fix/release-pipeline-recovery

Conversation

@sahenjp

@sahenjp sahenjp commented Nov 6, 2026

Copy link
Copy Markdown
Owner

What broke

The v0.29.0 and v0.30.0 GitHub releases exist, but no container images were published for them (GHCR stops at 0.28.0). Two distinct failures in release.yml, plus a structural gap:

  1. v0.29.0 — plan job, ci-gate race. The release was dispatched before main CI for the release commit finished (plan failed 23:05:02Z with the exact release commit has no successful main push CI run; CI only succeeded 23:08:15Z). Once release-please had created the release, later workflow_run passes reported created=false and never retried the publish.
  2. v0.30.0 — stage job, published-but-assetless release. release-please published the release (02:18:48Z) before the publish job reached stage. Stage treated already published as already staged and died in gh release download with no assets to download (02:29:38Z). The duplicate tag-push run was also cancelled with zero jobs, leaving no surviving publish path.
  3. Recovery gap. The container job was gated on stage.outputs.published != true, so a release whose assets are complete but whose image was never pushed could not be recovered by re-running release.yml: publish would look up a nonexistent image tag.

Changes (release.yml only)

  • plan: poll the ci-gate for up to 15 minutes (re-fetching runs; early exit if main CI completed without success); plan timeout 20 -> 30 min.
  • stage: if the release is published but has no assets, fall through and stage the built assets. A published release with assets is still verified as before and never overwritten; a partial set still fails loudly.
  • container: run whenever stage succeeds. docker.yml manifest is retry-safe: an existing version tag is verified against the source sha and its digest reused.

Recovery for v0.30.0 / v0.29.0

LICENSE and NOTICE (taken from each tag) were added to both releases; their uploaded asset sets now pass release_tools.py verify (14 files). After this merges, re-dispatching release.yml with dry_run=false for v0.30.0 (and v0.29.0 as a backfill) publishes the missing images and repairs the latest / minor aliases.

- plan: wait for the main CI run for the release commit instead of failing the ci-gate when a dispatch outruns CI (v0.29.0 failure: plan died at 23:05Z while CI only succeeded at 23:08Z)
- stage: a release published by release-please but still assetless falls through to staging the built assets instead of dying in gh release download (v0.30.0 failure: no assets to download)
- container: run the container job whenever stage succeeds, not only for unpublished releases; docker.yml manifest is retry-safe and reuses an existing version tag after verifying the source sha
@sahenjp
sahenjp merged commit 5535a15 into main Nov 6, 2026
14 checks passed
@sahenjp
sahenjp deleted the fix/release-pipeline-recovery branch November 6, 2026 05:26
sahenjp pushed a commit that referenced this pull request Nov 8, 2026
🤖 I have created a release *beep* *boop*
---


##
[0.31.0](v0.30.0...v0.31.0)
(2026-11-08)


### Features

* raw content statuses, renderer fallback and configurable body limit
([#128](#128))
([b893f1d](b893f1d))


### Bug Fixes

* **release:** recover image publishing for already-published releases
([#117](#117))
([5535a15](5535a15))

---
This PR was generated with [Release
Please](https://github.com/googleapis/release-please). See
[documentation](https://github.com/googleapis/release-please#release-please).

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant