Repository navigation
NO-ISSUE: Sort gate check-runs by started_at, not nonexistent created_at - #936
Conversation
Found live on PR osac-project#927: native_gate_conclusion picked a real failure over a later real success for e2e-caas-gate, refusing to correct an already-mis-cancelled orphan that should have been fixed. Root cause: check-run objects have no created_at field at all (verified directly against the raw API response -- only started_at/completed_at exist). sort_by(.created_at) | last was therefore sorting on a field that's always null for every entry, so "last" just picked whichever check-run happened to come last in the API's response order, not the chronologically latest attempt. In osac-project#927's case, that meant an older failure run landed after a newer success run in the response, and the script trusted the failure. Switched to sort_by(.started_at), which every check-run has regardless of whether it has completed yet (unlike completed_at, which is null for anything still in_progress and would have the same problem in reverse). Verified against a mock of osac-project#927's exact two check-runs (success at 01:21:49, failure at 20:45:51) before pushing: now correctly identifies success as the latest attempt.
|
@eliorerz: This pull request explicitly references no jira issue. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: eliorerz The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository: osac-project/coderabbit/.coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 12 included reviews per hour; 10 remain after this review. WalkthroughThe stale E2E gate check now selects the latest matching native gate run by ChangesNative gate ordering
Priority: ⬇️ Low Estimated code review effort: 1 (Trivial) | ~5 minutes Change: Bug fix Suggested labels: Suggested reviewers: Merge Risk: ⚪ Minimal · up to The native gate ordering fix is supported by the supplied validation and introduces no identified merge-blocking risk. 🚥 Pre-merge checks | ✅ 11✅ Passed checks (11 passed)
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
E2E on CodeRabbit approvalCodeRabbit APPROVED — starting expensive e2e (PR run replay).
|
🧭 E2E Suite Selection (POC, informational only)
No AI validation needed -- nothing in this PR was recognized as relevant to any E2E suite. This comment is informational only; nothing is gated on it yet. |
Companion fix to osac-project/osac#936. Found live on osac PR #927: a manual cleanup script sharing this exact sort_by(.created_at) | last pattern picked a real failure over a later real success for e2e-caas-gate. Root cause: check-run objects have no created_at field at all (verified directly against the raw API response -- only started_at/completed_at exist). sort_by(.created_at) | last therefore sorts on a field that's always null for every entry, so "last" just picks whichever check-run happens to land last in the API's response order, not the chronologically latest attempt. This same pattern is used by latest_gate_conclusion and native_gate_job_success, which back both the OSAC-1735 auto-heal follow-up jobs (osac#542) and the workflow_run-based fork-PR handler (osac#934) -- both call into this file via the complete-stale-e2e-gates action. Switched both to sort_by(.started_at), which every check-run has regardless of whether it has completed yet (unlike completed_at, which is null for anything still in_progress and would have the same problem in reverse).
Urgent -- caused an incorrect result on PR #927
Found live: `native_gate_conclusion` picked a real failure over a later real success for `e2e-caas-gate`, refusing to correct an already-mis-cancelled orphan that should have been fixed.
Root cause: check-run objects have no `created_at` field at all -- verified directly against the raw API response, only `started_at`/`completed_at` exist. `sort_by(.created_at) | last` was therefore sorting on a field that's always `null` for every entry, so "last" just picked whichever check-run happened to land last in the API's response order, not the chronologically latest attempt. In #927's case, an older failure run landed after a newer success run in the response, and the script trusted the failure.
Fix
Switched to `sort_by(.started_at)`, which every check-run has regardless of whether it has completed yet (unlike `completed_at`, which is null for anything still `in_progress` and would have the exact same problem in reverse).
Test plan
Also worth knowing
The identical `sort_by(.created_at)` pattern exists in `osac-test-infra`'s `e2e-gates-lib.sh` (used by the #542 auto-heal follow-up jobs and my #934 `workflow_run` handler) -- same bug, different repo. Opening a companion fix there.
CI
native_gate_conclusionnow sorts native gate check-runs bystarted_at.created_atfield is not available on check-run objects.API surface
Backward compatibility
Risk classification
risk:shipapplies because the change is limited to CI result ordering and changes one line.risk:showcriteria because it does not affect user-visible product behavior.risk:askcriteria because it does not affect security, persistence, deployment, or public APIs.