fix(ci): harden the tracking-issue fallback in the shared reporter - #10
Conversation
Review of the rollout PRs raised two problems with the issue fallback, both inherited from the copies this workflow replaced: - The issue title was spliced into the `--jq` program, so a title containing a double quote broke the filter. Match it through the environment instead. - Deduplication went through `gh issue list --search`, but the search index is only eventually consistent: two failures in quick succession each opened their own issue. Verified by running the workflow twice in a row, which produced duplicate issues. Filter by a `nightly-edge-failure` label instead, which goes through the GraphQL listing and sees the issue immediately. Also document pinning callers to a commit SHA and passing the webhook secret explicitly rather than `secrets: inherit`. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
Warning Review limit reached
Next review available in: 99 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the 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 configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
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. Comment |
There was a problem hiding this comment.
Pull request overview
Hardens the tracking-issue fallback path in the shared report-scheduled-failure reusable workflow to avoid jq filter breakage/injection and to prevent duplicate tracking issues when runs fail in quick succession.
Changes:
- Switch tracking-issue lookup to match the title via
env.TITLEinside the jq program (avoids quote-related jq breakage). - Replace
--search-based dedupe with a label-based dedupe (nightly-edge-failure) and add the label on issue creation. - Update caller documentation to recommend pinning the reusable workflow to a full commit SHA and explicitly mapping secrets.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| # Pin to a full commit SHA rather than a branch: `secrets: inherit` and mutable | ||
| # refs together would let any later change here run with the caller's secrets. | ||
| # Dependabot's github-actions ecosystem updates `jobs.<id>.uses` pins, so the | ||
| # clients still get changes made here without hand-editing eight workflows. |
| gh label create "$LABEL" --force \ | ||
| --color d93f0b --description "Nightly CI run against falkordb/falkordb:edge is failing" |
Summary
Follow-up to #5, addressing review feedback on the rollout PRs. Two problems with the tracking-issue fallback, both inherited from the eight copies the shared workflow replaced:
--jqprogram, so a title containing a double quote broke the filter.gh issue list --search, but GitHub's search index is only eventually consistent. Two failures in quick succession each opened their own issue.Problem 2 is not theoretical: I ran the workflow twice in a row via a temporary dispatch harness and it opened two identical issues. The
--limit 100fix originally suggested for the pagination concern would not have helped, since the issue simply is not in the index yet.Changes
env.TITLEinside the jq program instead of string-splicing it.nightly-edge-failurelabel instead of--search. Label filtering goes through the GraphQL listing, which is immediately consistent. The label is created idempotently withgh label create --force.Testing
actionlintclean. Verified end to end against a temporary dispatch harness in this repo, with the webhook deliberately unset so the issue path is exercised:"and$Harness, label, test issues and workflow runs have all been cleaned up.
Memory / Performance Impact
N/A — CI configuration only.
Related Issues
Follow-up to #5.