DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
This is a guide for the author to know the lifecycle of a PULL REQUEST.
PR Lifecycle
----------------
1. Author submits PR — fill in title, description, and checklist
2. Author triggers CI — comment "run buildall" on the PR to trigger TeamCity CI pipelines
3. Reviewer reviews code — comment "/review" on the PR to trigger AI review, approve or request changes
4. Committer merges — after CI passes and 1 approval received
5. Maintainer handles backport — add branch label, resolve conflicts, add version label
1. Submitting a PR
----------------
PR Title Format:
[type](module) short description
type options:
fix — Bug fix
feat — New feature
opt — Performance optimization
refactor — Code refactoring
Examples:
[fix](hive) fix wrong column separator when reading hive text format table
[feat](nereids) support window function with range frame
PR Description — cover whichever apply:
- Problem: What bug was fixed?
- Behavior change: What existing behavior changed?
- Feature: What new functionality was added?
- Refactor: What code was restructured?
Author Checklist (before submitting):
[ ] Unit tests and/or regression tests have been added
[ ] Documentation updated if there are user-visible behavior changes
2. Triggering CI
----------------
CI checks include GitHub Actions and TeamCity Pipelines.
Comment `run buildall` on your PR to trigger all TeamCity pipelines.
You can also trigger individual TeamCity checks:
run compile — COMPILE (DORIS_COMPILE)
run feut — FE UT (Doris FE UT)
run beut — BE UT (Doris BE UT)
run cloudut — Cloud UT (Doris Cloud UT)
run p0 — P0 regression (Doris Regression)
run cloud_p0 — cloud_p0 (Doris Cloud Regression)
run vault_p0 — vault_p0 (Doris Cloud Regression)
run nonConcurrent — NonConcurrent Regression (nonConcurrent)
run external — External Regression (Doris External Regression)
run performance — performance (Doris Performance)
Comment `/review` on your PR to trigger 'code-review'
Other GitHub Actions will auto-trigger after 1 Apache Doris Committer approval.
Required checks now:
- Check for secrets
- Clang Formatter
- CheckStyle
- P0 Regression (Doris Regression)
- NonConcurrent Regression (nonConcurrent)
- External Regression (Doris External Regression)
- cloud_p0 (Doris Cloud Regression)
- vault_p0 (Doris Cloud Regression)
- FE UT (Doris FE UT)
- BE UT (Doris BE UT)
- Build Broker
- Build Third Party Libraries (Linux)
- Build Third Party Libraries (macOS)
- Build Third Party Libraries (macOS-arm64)
- COMPILE (DORIS_COMPILE)
- code-review
- Cloud UT (Doris Cloud UT)
- performance (Doris Performance)
- check_coverage (Coverage)
note:
- TeamCity pipelines include 3 stages: (compile feut beut cloudut performance) → (p0 cloud_p0 vault_p0 external nonconcurrent) → (check_coverage). Stage 2 depends on compile completed, Stage 3 depends on all Stage 2 pipelines completed.
If you have some test files that need to be uploaded to a test-specific object storage bucket, please @hello-stephen in your PR to ask for help to upload them.
3. Code Review and Merging
----------------
A PR can be merged only when ALL of the following are met:
1. AI reviewd and at least 1 Apache Doris Committer approved
2. Code owners of all affected modules have approved
3. All required CI checks have passed
Reviewer Checklist:
[ ] Code logic is correct and test coverage is sufficient
[ ] Release notes updated if there are user-visible changes
[ ] Correct backport labels applied (if needed)
4. Backport
----------------
To backport to a release branch, add the label BEFORE merging:
dev/2.1.x → branch-2.1
dev/3.0.x → branch-3.0
dev/3.1.x → branch-3.1
dev/4.0.x → branch-4.0
dev/4.1.x → branch-4.1
Adding a label automatically triggers a cherry-pick.
- If conflicts occur, a "conflict" label is added automatically.
Resolve the conflicts manually and resubmit.
- After the backport PR is merged, add a version label
(e.g. dev/2.1.8-merged) to track which release includes the fix.