Skip to content

Create the GitHub release only after the image is published - #256

Merged
rbardaji merged 1 commit into
mainfrom
feature/255-publish-release-after-image
Aug 26, 2026
Merged

Create the GitHub release only after the image is published#256
rbardaji merged 1 commit into
mainfrom
feature/255-publish-release-after-image

Conversation

@rbardaji

Copy link
Copy Markdown
Collaborator

Closes #255.

The problem

#252 automated the Docker Hub publish but kept the wrong ordering: the release
was published first, and the image was built from that event. Anything failing
in between left a published release whose image had never been pushed, so
docker pull served the previous version while the release notes described the
new one — the exact gap the automation was meant to close.

Releasing 0.34.18 hit this twice: once on a Docker Hub credentials error, and
once on a GitHub Actions outage that produced a startup_failure before any job
was created. Both times the release stayed published and Docker Hub kept serving
0.34.17.

The change

The workflow now triggers on a v* tag being pushed, and creates the release as
its final step, once the image is on Docker Hub.

A failed run leaves no release at all. Re-running the workflow for the same
version finishes the job without cutting a new tag — the release step updates an
existing release rather than failing on it.

Triggering on a draft release, as the issue originally proposed, is not
possible: GitHub does not emit release events for drafts.

Release notes

Notes come from that version's CHANGELOG.md section, via the new
scripts/extract_changelog.py, so the release page and the changelog cannot
drift apart. Releasing the Unreleased section is refused explicitly, and a
version with no section fails the run before anything is built.

Prereleases

With no release object to read prerelease from, it is derived from the version
itself: a SemVer prerelease identifier (v0.35.0-rc1) publishes under its own
tag only, leaves latest alone, and marks the GitHub release as a prerelease.

Effect on the release procedure

gh release create is no longer run by hand — the workflow does it. Releasing is
now: bump swagger_version and the CHANGELOG, commit, then push the tag. The
README section is rewritten accordingly.

Testing

  • 16 new tests for the changelog extractor: section boundaries, the last section
    running to end of file, the heading and date being dropped, unknown versions,
    empty sections, and the three exit codes.
  • Full suite: 1269 passed.
  • black --check . clean across 253 files; flake8 api/ tests/ scripts/ clean.
  • Tag resolution verified for v0.34.19, v0.35.0-rc1, v1.0.0-beta.2 and
    v1.0.0, on both the tag-push and manual-dispatch paths.

The workflow's own end-to-end behaviour is first exercised by the next release.

The release was published first and the image was built from that event,
so anything failing in between left a published release whose image had
never been pushed. `docker pull` then served the previous version while
the release notes described the new one — the exact gap the automated
publish was meant to close.

It is not hypothetical: releasing 0.34.18 hit it twice, once on a Docker
Hub credentials error and once on a GitHub Actions outage that produced a
startup failure before any job existed.

Trigger the workflow on a `v*` tag being pushed instead, and create the
release as the final step, once the image is on Docker Hub. A failed run
leaves no release at all, and re-running for the same version finishes
the job without cutting a new tag. Triggering on a draft release was not
an option: GitHub does not emit release events for drafts.

Take the notes from that version's CHANGELOG section via
scripts/extract_changelog.py, so the release page and the changelog
cannot drift apart, and refuse to release the Unreleased section.

Derive prerelease status from the SemVer version, since there is no
release object to read it from any more: a tag like v0.35.0-rc1 is
published as a prerelease and does not move `latest`.

Closes #255
@rbardaji
rbardaji merged commit 8d6fe2a into main Aug 26, 2026
1 check passed
@rbardaji
rbardaji deleted the feature/255-publish-release-after-image branch August 26, 2026 19:50
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.

A failed image publish should not leave a published release without its image

1 participant