Trigger CI on published releases so versioned Docker tags get pushed - #27
Merged
Conversation
The docker job has a "Build and push :<tag> on release" step gated on github.event_name == 'release', but the workflow's on: block only listed push and pull_request. A workflow that is never triggered by a release event can never satisfy that condition, so the step has never run. Across the last 100 workflow runs the event breakdown is push 69, pull_request 31, release 0, while nine releases have been published (1.0.0 through 1.4.1). Docker Hub correspondingly carries a single tag: both the Hub API (count: 1) and the registry v2 tags/list return only ":latest", which is refreshed by the separate push-to-main step. Adding the release trigger is sufficient. The test job has no if: condition so it runs on release events, the docker job's existing if: already admits them, and coverage-pages stays gated on push-to-main. On a published release the PR-only and push-to-main steps skip and the release step pushes <user>/alphajudge:<tag_name>. Note this is not retroactive: images for the already-published 1.0.0-1.4.1 releases would still need a manual build or a re-published release. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
dockerjob has a "Build and push : on release" step gated ongithub.event_name == 'release', but the workflow'son:block only listedpushandpull_request. A workflow that is never triggered by a release event can never satisfy that condition, so the step has never run.Evidence
Across the last 100 workflow runs:
pushpull_requestreleaseMeanwhile nine releases have been published (1.0.0 through 1.4.1). Docker Hub correspondingly carries a single tag — confirmed two ways:
/v2/repositories/kosinskilab/alphajudge/tags→count: 1/v2/kosinskilab/alphajudge/tags/list→["latest"]That one tag comes from the separate push-to-main step, which is why it exists and nothing else does.
The fix
Adding the trigger is sufficient; no job conditions need changing:
testhas noif:, so it runs on release events and satisfiesneeds: testdocker's existingif:already admitsrelease/publishedcoverage-pagesstays gated on push-to-main and correctly skipsOn a published release the PR-only and push-to-main steps skip, and the release step pushes
<user>/alphajudge:<tag_name>.As a side effect this also clears the static-analysis warning on
github.event.release.tag_name, which was flagged as an invalid context precisely because noreleasetrigger was declared.Not retroactive
Images for the already-published 1.0.0–1.4.1 releases are not backfilled by this change; those would need a manual build/push or a re-published release.
🤖 Generated with Claude Code