ci: run on every push and PR, without path filters - #52
Conversation
Branch protection is going on main, and a required check that a path filter skips is never reported at all. GitHub cannot tell that apart from a check that has not started, so the PR waits on a status that will never arrive and cannot be merged without an admin override. The stele workflows' own trigger comment anticipated this and named dropping the filters as the fix. This is that change, applied to all four repositories that are getting protected branches. Costs redundant runs on docs-only PRs, which is the cheaper side of the trade against a small PR that can never be merged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018jrcs1EZH6uiXusw33t3KJ
ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Free Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe CI workflow now runs for every push to ChangesCI Trigger Coverage
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to This change makes the existing CI checks run for every pull request and push to main, preventing required checks from being skipped while adding only redundant runs for documentation-only changes. No actionable merge-blocking risk remains beyond normal checks and review. Poem
Note 🎁 Summarized by CodeRabbit FreeYour organization is on the Free plan. CodeRabbit will generate a high-level summary and a walkthrough for each pull request. For a comprehensive line-by-line review, please upgrade your subscription to CodeRabbit Essentials by visiting https://app.coderabbit.ai/settings/billing. Comment |
1 participant
Drops the path filters from the CI trigger, so the workflow runs on every push to
mainand every pull request.This is a prerequisite for branch protection, not a change anyone wanted for its own sake. A required status check that a path filter causes to be skipped is never reported to GitHub at all, and GitHub cannot distinguish "skipped because the filter excluded it" from "hasn't run yet" — so the PR sits at "Expected — waiting for status to be reported" permanently, with nothing the author can do to satisfy it. The only escapes are an admin override on every docs-only PR or removing the check from the required list, which defeats the point of requiring it.
The stele repos' own trigger comment already called this out and named dropping the filters as the resolution, so this is that change.
The cost is redundant runs on documentation-only PRs. That is the cheaper half of the trade: a few wasted runner-minutes against a merge queue that can deadlock on exactly the kind of small PR that should be easiest to land.
🤖 Generated with Claude Code
https://claude.ai/code/session_018jrcs1EZH6uiXusw33t3KJ
Summary by CodeRabbit