ci: stop evaluate failing when a PR's CI is pending or red

[xdustinface]

Problem

The evaluate job in the "Ready for Review Label" workflow goes red on pull requests whenever the PR's own CI is not fully green. This is highly visible on fork PRs (for example #837), where it shows a failing check right on the automation #838 was meant to make work.

Root cause

.github/scripts/check_ci_status.sh runs under set -euo pipefail, and its one real command is:

gh pr checks "$PR_NUMBER" --repo "$REPO" --json name,bucket --jq '...'

gh pr checks reports the check rollup through its exit code, even with --json: it exits 8 when any check is still pending and non-zero when any check has failed. Under set -e the script therefore aborts before echoing its status whenever the PR's CI is pending or red. The caller assigns that output with CI_STATUS=$(check_ci_status.sh ...), also under set -e, so the failed command substitution takes the whole evaluate job down with "exit code 1".

The gh pr checks gotcha predates #838, but that PR's workflow_run relay made it surface constantly: evaluate now re-runs on every review and label event, routinely while CI is still pending or red, which is exactly when gh pr checks returns non-zero.

Fix

Capture the JSON with || true so the non-zero exit no longer aborts the caller, and treat empty output as no_checks. The existing jq rollup then classifies pending / has_failures / all_passed as intended, so evaluate exits 0 and simply removes the label while CI is unfinished, then adds it once everything is green.

No behavior change when CI is fully green. Verified the rollup still returns all_passed, pending, has_failures, and no_checks for the corresponding check states, including correctly excluding the gate jobs (validate-triggers, evaluate, ready-for-review-trigger) from the tally.

Summary by CodeRabbit

• Bug Fixes
  • Improved CI status handling so pending checks no longer cause the status script to stop early.
  • More reliably detects when no checks are available and classifies PR check results correctly.

[coderabbitai]

Warning

Review limit reached

@xdustinface, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 36 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: ddc03faa-9d79-4410-a910-87c7e32615bb

📥 Commits

Reviewing files that changed from the base of the PR and between 4d80880 and ce6942d.

📒 Files selected for processing (1)

• .github/scripts/check_ci_status.sh

📝 Walkthrough

Walkthrough

The CI status script's gh pr checks invocation was changed to capture JSON output into a variable while suppressing command exit codes, preventing early script termination on set -e when checks are pending. Empty output is now handled explicitly by echoing no_checks before proceeding to existing jq-based classification logic.

Changes

CI Status Script Fix

Layer / File(s)	Summary
Capture gh pr checks output and handle pending state .github/scripts/check_ci_status.sh	Changed gh pr checks invocation to capture JSON output into CHECKS while suppressing non-zero exit codes that previously caused early termination under set -e; added handling to echo no_checks when output is empty before continuing to jq classification.

Estimated code review effort: 1 (Trivial) | ~5 minutes

Possibly related PRs

• dashpay/rust-dashcore#838: Both PRs modify the CI check-state aggregation logic in the same script file.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly summarizes the main fix: preventing evaluate from failing while PR CI is pending or failing.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.github/scripts/check_ci_status.sh:
- Around line 11-20: The CHECKS capture in check_ci_status.sh is swallowing all
gh pr checks failures, so unexpected auth/rate-limit/network errors are
misclassified as no_checks. Update the logic around the gh pr checks call to
distinguish the expected non-zero exit cases from real failures, keep stderr
visible for unexpected errors, and only treat truly empty JSON output as
no_checks before the jq rollup runs.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: a9cce095-4220-4972-af76-7e45bcb61275

📥 Commits

Reviewing files that changed from the base of the PR and between 417d61d and 4d80880.

📒 Files selected for processing (1)

• .github/scripts/check_ci_status.sh

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 73.36%. Comparing base (417d61d) to head (ce6942d).

Additional details and impacted files

@@            Coverage Diff             @@
##              dev     #844      +/-   ##
==========================================
+ Coverage   73.33%   73.36%   +0.02%     
==========================================
  Files         324      324              
  Lines       72923    72923              
==========================================
+ Hits        53478    53498      +20     
+ Misses      19445    19425      -20     

Flag	Coverage Δ
core	76.94% <ø> (ø)
ffi	45.49% <ø> (ø)
rpc	20.00% <ø> (ø)
spv	90.65% <ø> (+0.11%)	⬆️
wallet	72.97% <ø> (ø)
see 6 files with indirect coverage changes