fix: refuse a ci-result schema the action cannot read, and bound the patchrail install - #6
Merged
Merged
Conversation
…patchrail install The action installed patchrail unpinned, and `annotate.py` read every ci-result field with `.get()`. A patchrail release that changes the ci-result contract therefore lands in every consumer's CI with no commit here, and does not raise: it degrades to `unknown (confidence None)` pointing at the bare guide index, on a run that is already red, under a `@v1` tag pinned precisely so nothing would move. It was also silent. The smoke assertions (`test -n` on the class, a `fix*` glob on the URL) both pass on that output, so CI would have stayed green while users saw meaningless annotations. This is not hypothetical: patchrail 0.4.0 moved `ci classes` to schema v2 in a minor bump. - annotate.py checks `schema_version` and, when it is not the one it reads, names both versions and the way out instead of inventing a classification. Empty outputs, exit 0: it runs under `if: failure()`, so a second red step would bury the failure the user came to see. - action.yml installs `patchrail>=0.3.1,<0.5.0` by default (verified: both emit `patchrail.ci_result.v1`), so a breaking release cannot reach users on its own. - The guide-slug job installs that same range, grepped out of action.yml so the two cannot drift, and the new `latest-patchrail` job runs the real explain -> annotate path against the newest release on PyPI. A breaking release now turns this repo red before it turns users red, without blocking `@v1`. - The smoke assertions check the class the sample log actually is, so a degraded result can no longer pass them.
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
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 bug
The action installs
patchrailunpinned, andscripts/annotate.pyreads every ci-result field with.get(). So a patchrail release that changes the ci-result contract lands in every consumer's CI with no commit here to review — and it does not raise. It degrades:That is a confident-looking PatchRail annotation, on a run that is already red, that says nothing — under a
@v1tag users pinned precisely so nothing would move under them.And it was silent: the smoke assertions (
test -non the class, afix*glob on the URL) both pass on exactly that output, so CI would have stayed green while every user saw garbage. Not hypothetical — patchrail 0.4.0 movedci classesto schema v2 in a minor bump.The fix
annotate.pychecksschema_versionand, when it is not the contract it reads, names both versions and the way out (patchrail-version, or upgrade the action) instead of inventing a classification. Empty outputs, exit 0 — it runs underif: failure(), where a second red step buries the failure the user actually came to debug.action.ymlinstallspatchrail>=0.3.1,<0.5.0by default (verified: 0.3.1 and 0.4.0 both emitpatchrail.ci_result.v1), so a breaking release cannot reach users on its own. Pinning an exact version viapatchrail-versionis unchanged.latest-patchrailjob runs the realexplain -> annotatepath against the newest patchrail on PyPI, every push and weekly. A breaking release now turns this repo red before it turns users red. It is deliberately not a gate onsync-v1: the guide-slug job installs the shipped range instead (grepped out ofaction.ymlso the two cannot drift), so an upstream break can never stop merged fixes from reaching@v1.Verification
python_test_failure(0.89) →/fix/python-test-failure.ci_result.v2: no invented class, empty outputs, message naming both schemas.