chore: review workflow supports merge conflicts — Phase A0 before CI failures - #220
Merged
Conversation
…failures /github-review-pr gains a conflicts-first phase: detect via mergeable (with a local git merge-tree fallback for the sticky UNKNOWN state), merge the base in (never rebase a shared branch), resolve semantically with repo-specific rules (regenerate min.js + vendored twins from source, union CHANGELOG entries, base wins version.rb, base + bundle install for docs/Gemfile.lock, keep both sides of append-only registries), gate before pushing. Loop-back rules, final-report sections, and a pre-flight guard in /github-review-failures included; a merged PR now short-circuits with a report instead of a phantom review.
- UNKNOWN fallback now tests the PR's ACTUAL head (fetch pull/<PR>/head + merge-tree against FETCH_HEAD), verifies both refs resolve first (a bad ref also exits 1 — exit code alone is untrustworthy), and reads --name-only output as the work list; checkout moved to the resolution procedure's start. - version.rb rule inverted where it matters: releases land direct-to-main via rake release, so a version.rb conflict means the BRANCH bumped on purpose — keep the branch's bump or ask, never silently revert a release-prep PR. - Vendored-artifact rule scoped to the FIVE generated twins from the sync spec's map; stimulus/turbo/shims/dummy reducers are ordinary sources. - Docs gate cites the canonical rake lint (bare rubocop in docs/ inspects 0 files); allowed-tools now covers everything Phase A0 runs (gh pr checkout, git switch/rev-parse, bundle install, cp, cd). - /github-review-failures pre-flight reduced to detection-only + hand-off — its own toolset can't run the resolution, by design.
Contributor
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 26 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. 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: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Comment |
This was referenced Jul 9, 2026
Merged
chore: review workflow supports merge conflicts — Phase A0 before CI failures
zoolutions/docs-kit#60
Merged
Merged
Merged
mhenrixon
added a commit
to zoolutions/daisyui
that referenced
this pull request
Jul 9, 2026
…failures (#35) * chore: review workflow supports merge conflicts — Phase A0 before CI failures Backport of zoolutions/phlex-reactive#220, adapted to this repo: - New /github-review-pr orchestrator: Phase A0 (merge conflicts) runs before CI failures, which run before review comments. Detection via gh pr view --json mergeable with a local git merge-tree fallback that tests the PR's actual head (git fetch origin pull/<PR>/head + FETCH_HEAD), ref verification before trusting exit codes, and the --name-only conflict list as the work list. Resolution is merge-never-rebase with repo-specific semantic rules. - /github-ci-failures gains a detection-only merge-conflict pre-flight that hands off to the orchestrator, plus a check-name table matching the actual CI jobs (Lint, Gem Tests, Docs Lint, Docs Tests). - allowed-tools frontmatter now covers every command each runbook instructs (gh pr list/checkout, git fetch/merge/merge-tree/rev-parse/ status/switch, bundle install, bun, docs bin/rubocop). * fix: address backport verification findings
mhenrixon
added a commit
to zoolutions/pgbus
that referenced
this pull request
Jul 9, 2026
…failures (#349) * chore: review workflow supports merge conflicts — Phase A0 before CI failures Backport of zoolutions/phlex-reactive#220 adapted to pgbus. /github-review-pr gains Phase A0: detect conflicts via gh pr view --json mergeable with a local git-merge-tree fallback against the PR's actual head (fetch pull/<PR>/head, verify refs before trusting exit codes), then resolve with a merge (never rebase), semantic per-file rules adapted to this repo (CHANGELOG union, version.rb stays with base per RELEASING.md, frozen lockfiles never bundle lock'd, compiled style.css + vendored turbo/apexcharts never hand-merged, append-only registries), CI-mirroring verification gates, and a plain push. Phase C re-checks mergeability; new conflicts loop back to A0. /github-review-failures gains a detection-only pre-flight that hands CONFLICTING PRs to the orchestrator, and its check-name table now matches main.yml's actual job names. * fix: address backport verification findings The style.css conflict rule instructed regenerating with the Tailwind CLI, but pgbus ships no build tooling for the dashboard CSS (no tailwindcss dep in the root package.json, no rake/bin task; docs/'s CLI is a newer version wired to the docs app). Soften the rule to the vendor-file treatment — resolve the source, take one side of the compiled file whole — and name the exact ad-hoc regeneration command (version-pinned bunx) for the both-sides-changed case, adding Bash(bunx:*) to allowed-tools so it is executable.
mhenrixon
added a commit
to zoolutions/sidekiq-unique-jobs
that referenced
this pull request
Jul 9, 2026
…failures (#973) * chore: review workflow supports merge conflicts — Phase A0 before CI failures Backport of zoolutions/phlex-reactive#220 adapted to this repo. - New /github-review-pr orchestrator: Phase A0 detects conflicts via gh pr view --json mergeable with a local git merge-tree fallback against the PR's actual head (git fetch origin pull/<PR>/head + FETCH_HEAD, refs verified before trusting exit codes), resolves by MERGE (never rebase), and gates the push on rubocop + the touched specs. - Repo-specific resolution rules: generated CHANGELOG.md (github_changelog_generator) and doc/ (YARD) are never hand-merged; version.rb conflicts mean a deliberate release-prep bump (releases land directly on main via rake release); myapp/Gemfile.lock and myapp/bun.lock re-resolve via bundle/bun install; Lua sources merge semantically with the script + lock specs as the gate. - github-ci-failures.md renamed to github-review-failures.md (the name the orchestrator invokes) and given a detection-only merge-conflict pre-flight that hands off to /github-review-pr. - github-review-comments.md unchanged — #220 did not touch it and the existing copy is already adapted to this repo. * fix: address backport verification findings - github-review-failures.md: add Bash(gh pr list:*) and Bash(git branch:*) to allowed-tools — Phase 0's auto-detect instructs both, but neither was allowlisted, forcing a permission prompt on standalone runs. - github-review-pr.md: phrase the lockfile rule generically (any committed Gemfile.lock/bun.lock, re-resolve in that directory) so it stays true when the docs-kit site (#972) adds tracked docs/ lockfiles.
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
1 participant
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
/github-review-pr gains Phase A0: merge conflicts, running BEFORE the CI-failures phase — CI results only matter for the code that will actually merge, and resolving conflicts first means failure diagnosis reads the post-merge reality (one extra CI cycle instead of two).
gh pr view --json mergeablewith a localgit merge-tree --write-treefallback for the stickyUNKNOWNstate (no polling).*.min.js, maps,spec/dummy/public/vendor/*.js): never hand-merge — resolve the source,rake build:js, re-sync (the existing guards catch violations)CHANGELOG.mdUnreleased: union both sideslib/phlex/reactive/version.rb: base wins (releases bump on main viarake release)docs/Gemfile.lock(the only tracked lockfile): base wins, thenbundle installindocs//github-review-failuresgets a pre-flight mergeability guard pointing at Phase A0.Test plan
Doc-only change to two command runbooks; exercised by the next
/github-review-prrun. An adversarial verification pass (repo-rule consistency + scenario probing) runs in the background — any findings land as a follow-up commit on this PR.Deviations & judgment calls
Gemfile.lockis gitignored — the lockfile rule names onlydocs/Gemfile.lock(verified viagit ls-files).