Skip to content

feat(chapel-ci): always-on aggregator gate to fix path-filtered required-checks#90

Merged
hyperpolymath merged 1 commit into
mainfrom
feat/chapel-ci-aggregator-gate
May 30, 2026
Merged

feat(chapel-ci): always-on aggregator gate to fix path-filtered required-checks#90
hyperpolymath merged 1 commit into
mainfrom
feat/chapel-ci-aggregator-gate

Conversation

@hyperpolymath
Copy link
Copy Markdown
Owner

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

  1. `on:` block drops the `paths:` filter — workflow triggers on every PR.
  2. New `detect-relevant-changes` job diffs against the PR base and sets
    `outputs.relevant = true|false` using the same path list that lived
    in the on-trigger.
  3. Each of the six gates gains `needs: detect-relevant-changes` +
    `if: needs.detect-relevant-changes.outputs.relevant == 'true'`. They
    skip cleanly on irrelevant PRs.
  4. `chapel-ci-gate` job (`if: always()`, `needs: [all 6 + detect]`):
    • SUCCESS immediately if no chapel-relevant paths changed.
    • SUCCESS if all 6 underlying jobs returned `success`.
    • FAILURE if any underlying job failed/cancelled.

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"}]' \

/tmp/patch.json
gh api -X PUT repos/hyperpolymath/panic-attack/rulesets/14968583 --input /tmp/patch.json
```

Test plan

  • All 6 chapel-ci jobs green on this PR (workflow self-tests itself)
  • chapel-ci-gate green on this PR
  • After merge: ruleset PUT switches required check from 6 → 1
  • Verify next non-chapel PR is no longer blocked by chapel-ci

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

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>
@hyperpolymath hyperpolymath force-pushed the feat/chapel-ci-aggregator-gate branch from 93161aa to 20dee29 Compare May 30, 2026 22:37
@hyperpolymath hyperpolymath merged commit f988566 into main May 30, 2026
@hyperpolymath hyperpolymath deleted the feat/chapel-ci-aggregator-gate branch May 30, 2026 22:38
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant