feat(chapel-ci): always-on aggregator gate to fix path-filtered required-checks#90
Merged
Merged
Conversation
This was referenced May 30, 2026
Merged
The six chapel-ci jobs are path-filtered (chapel/**, Cargo files, etc.) so they don't run on every PR. Path-filtered required status checks leave "expected but not reported" on unrelated PRs, blocking them indefinitely once the gates are in the Base ruleset. Replace that with a single always-on aggregator job (chapel-ci-gate): * Drop path filter from `on:` so the workflow triggers on every PR. * New `detect-relevant-changes` job inspects the diff and outputs `relevant=true|false` based on the same path list that used to live in the on-trigger. * Each of the six gates gains `needs: detect-relevant-changes` + `if: needs.detect-relevant-changes.outputs.relevant == 'true'`. * `chapel-ci-gate` job needs all six + detect, `if: always()`. Reports SUCCESS immediately if no chapel-relevant paths changed; otherwise inspects each dependent job's result and fails on any non-success. Next step (separate, post-merge): update the Base ruleset to require ONLY `chapel-ci-gate` instead of the six individual jobs. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
93161aa to
20dee29
Compare
2 tasks
hyperpolymath
added a commit
that referenced
this pull request
May 30, 2026
….md (#91) ## Summary Documentation tidy-up after the issue #33 closure merge sequence (#86 → #90 → #88 → #89). - **CHANGELOG.md**: merge two parallel `## [Unreleased]` headers into one with dated `### Added (2026-MM-DD)` subsections. Add a top-level S1–S3 milestone entry that captures what the broader issue #33 work actually delivered (hexad persistence, `campaign` + `query` subcommands) — the prior Unreleased blocks only documented the leaf-level query parser polish from #88 and the 2026-04-18 registry/Rocq work. - **CLAUDE.md**: move "Interactive TUI mode" from "Planned Features" to "Shipped Features" — it's already implemented (`src/report/tui.rs` with `ReportTui::run()` / `run_headless()`, `crossterm = "0.29"` in Cargo.toml). Add VeriSimDB hexad persistence and Chapel CI infrastructure to Shipped. Keeps the verisimdb HTTP API and Chapel metalayer (distributed orchestration) in Planned where they still belong. ## Test plan - [x] Doc-only edit — no code changed - [x] `chapel-ci-gate` (the single required check on the Base ruleset) is path-filtered to chapel sources; should skip cleanly for a docs-only PR via the always-on aggregator gate that landed in #90 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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.
Summary
Closes a soft regression introduced by the chapel-ci ruleset patch:
the six chapel-ci jobs are path-filtered, so they only run on PRs that
touch chapel/** / Cargo / src/main.rs. When the Base ruleset requires
those job contexts, PRs that don't touch any of those paths leave the
required checks "expected but not reported" — they get blocked
indefinitely.
The fix is an always-on aggregator pattern: a single `chapel-ci-gate`
job replaces the six individual jobs as the required check.
Mechanics
`outputs.relevant = true|false` using the same path list that lived
in the on-trigger.
`if: needs.detect-relevant-changes.outputs.relevant == 'true'`. They
skip cleanly on irrelevant PRs.
Ruleset migration (post-merge, separate operation)
Currently the Base ruleset (id `14968583`) requires the 6 individual
chapel-ci jobs. Once this PR merges and `chapel-ci-gate` is proven
green on main, run:
```bash
gh api repos/hyperpolymath/panic-attack/rulesets/14968583 \
--jq 'del(.bypass_actors) | (.rules[] | select(.type=="required_status_checks") | .parameters.required_status_checks) |= [{"context": "chapel-ci-gate"}]' \
Test plan
Parallel work
The same pattern applies to ephapax #244 (Coq build oracle ruleset gap).
Once panic-attack proves the pattern, the same refactor lands on
`ephapax/.github/workflows/coq-build.yml`.
🤖 Generated with Claude Code