ci: judge each check by its newest run - #54
Merged
Conversation
Two separate causes left autoupdate PRs open again. 1. The merge gate counted cancelled leftovers as failures. autoupdate.yml dispatches CI, then claude.yml dispatches it again. Both are workflow_dispatch on the same branch, so they land in the same pr-checks concurrency group and the second cancels the first. The cancelled check runs stay on the commit, and the gate — which looked at every check run for the SHA — read them as failures. ireceipt-pro/js#37 was the casualty: Claude found nothing to fix, the winning run was green on all four checks, and the gate still reported "total=8 pending=0 failed=3" and refused to merge a healthy PR. The gate now keeps only the newest run of each check name (group_by(.name) | map(max_by(.id))) before judging. Verified against a fixture built from that PR's real check runs: 8/failed=3 becomes 4/failed=0, while a genuine later failure is still counted. 2. jsdom keeps being bumped back past Node 20. jsdom 30 declares engines.node ^22.22.2 || ^24.15.0 || >=26.0.0 and crashes on Node 20, which stripe-js tests. v2.0.80 already pinned it to ^29 for this reason; npm-check-updates walked it back to ^30 this week and broke the same job again. A pin in package.json cannot survive `ncu -u`, so jsdom joins ignore_packages for that repo. Dropping Node 20 from the matrix instead is a support-policy change, not a compatibility shim, so it stays the maintainer's call.
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
2 participants
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.
Rolls out from
siarheidudko/claude#8.Problem
The merge gate could refuse to merge a PR whose checks were actually green.
autoupdate.ymldispatches CI, thenclaude.ymldispatches it again. Both areworkflow_dispatchon the same branch, so they land in the samepr-checksconcurrency group and the second cancels the first. Those cancelled check runs stay attached to the commit, and the gate — which read every check run for the SHA — scored them as failures.Seen live in
ireceipt-pro/js#37: four green checks from the winning dispatch plus four leftovers from the superseded one, and the gate loggedtotal=8 pending=0 failed=3on a healthy PR.Fix
The gate keeps only the newest run of each check name before judging:
Applied in both
autoupdate.ymlandclaude.yml. Verified against a fixture built from that PR's real check runs:total=8 failed=3becomestotal=4 pending=0 failed=0, while a genuine laterfailureon the same name is still counted.Generated from the
siarheidudko/claudetemplates; no repo-specific hand edits.Generated by Claude Code