ci: run the catalog liveness check nightly instead of on every push - #108
Merged
Conversation
A release lands as merge-then-tag, so between those two moments the catalog genuinely points at releases that do not exist yet. Running the check on push therefore made `main` red by construction on every release: the 0.23.3 merge went red thirteen seconds after landing, for a condition that resolved as soon as the tags were pushed. A gate that is routinely red for a known-benign reason is one people learn to ignore, which costs more than the window it covers. Nightly still catches the failure it exists for, a set of tags that is never pushed at all, and workflow_dispatch covers the case where the answer is wanted immediately: run it by hand right after pushing release tags. Moves the job into its own workflow, matching download-badges.yml, which lets ci.yml go back to a single job with no event guards.
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 catalog liveness check landed in #107 wired to
pushonmain. That was the wrong trigger.A release lands as merge-then-tag, so between those two moments the catalog genuinely points at
releases that do not exist yet. The 0.23.3 merge went red thirteen seconds after landing, reporting ten
404s, for a condition that resolved as soon as the tags were pushed a minute later. That is not a false
positive in the sense of being wrong, it is worse: it is correct, benign, and guaranteed to recur on
every single release.
A gate that is routinely red for a known-benign reason is one people learn to ignore, which costs more
than the window it covers.
schedule(nightly) plusworkflow_dispatch, matching the shapedownload-badges.ymlalready uses.all, which is what left the catalog answering 404 for every plugin before fix: restore the catalog, verify against OpenWA 0.23.3, and correct plugin defects #107.
workflow_dispatchcovers the case where the answer is wanted immediately. Run it by hand rightafter pushing a set of release tags, which is exactly when you want to know.
ci.ymlgoes back to a single job with no event guards, since the two jobs no longer share triggers.No change to the check itself. Verified by running
node scripts/catalog-live-check.mjsagainst thenow-published 0.23.3 releases: ten plugins fetched, every sha256 pin matches.