Unverified Commit ef317da8 authored by Keiven C's avatar Keiven C Committed by GitHub
Browse files

fix: relax CodeRabbit rebase guideline to not check commit distance from main (#7475)


Signed-off-by: default avatarKeiven Chang <keivenchang@users.noreply.github.com>
parent 5b6624bd
# PR Workflow Guidelines
Conventions for keeping pull requests healthy and reviewable.
## Keep Your Branch Close to Main
Be aware of PRs targeting `main` that are more than ~25 commits behind.
Stacked PRs targeting another branch are exempt.
### 1. Slower CI builds
CI builds start from a base image matching a recent `main` commit. The closer
your branch is to `main`, the more cache hits you get. We use BuildKit with
remote cache (`--cache-from`), but BuildKit layers are still content-addressed
-- if a `COPY` brings in source that changed since your branch point, that
layer and everything downstream rebuilds regardless. When your branch is far
behind:
- **Docker layer cache misses**: Changed source or Dockerfile instructions
since your branch point invalidate cached layers, forcing rebuilds
downstream.
- **Rust compilation cache misses**: More crate sources differ from what's
cached, so more crates recompile from scratch.
- **Dependency drift**: `Cargo.lock` and `requirements.txt` evolve on `main`.
Stale branches pull older versions that aren't cached, triggering fresh
downloads and builds.
A branch too far behind `main` can trigger a near-cold build that takes
45-60 minutes. A branch close to `main` reuses most of the cache and builds
in a fraction of that time.
### 2. Reviewer burden
Merge commits from main pollute the diff with unrelated changes. Rebasing
produces a clean, linear history where every commit is the PR author's.
```bash
# BAD -- merge pulls in unrelated files; reviewer has to filter them out
git merge main
# GOOD -- clean diff showing only your work
git fetch origin && git rebase origin/main
```
### Guidance
- **Rebase when you are more than ~25 commits behind main.**
- **Prefer `rebase` over `merge`** for linear history. Force-push after
rebasing (`git push --force-with-lease`).
- **Before requesting review**, check your distance from main:
```bash
git fetch origin
git rev-list --count HEAD..origin/main
```
More than 25? Rebase first.
- **If CI is slow**, check your base commit age before debugging other causes.
- **Stacked PRs** are exempt. If a PR targets another branch in a stack,
distance from `main` is expected and not a problem until the stack lands.
...@@ -28,11 +28,6 @@ reviews: ...@@ -28,11 +28,6 @@ reviews:
unit_tests: unit_tests:
enabled: false enabled: false
path_instructions: path_instructions:
- path: "**"
instructions: |
Flag PRs more than ~25 commits behind main. Recommend rebasing.
Exception: stacked PRs targeting another branch are exempt.
See .ai/pr-workflow-guidelines.md.
- path: "**/*.py" - path: "**/*.py"
instructions: "Review against .ai/python-guidelines.md" instructions: "Review against .ai/python-guidelines.md"
- path: "**/tests/**/*.py" - path: "**/tests/**/*.py"
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment