[CI/Build] Add advisory PR title format check (#54263)
Bugen Zhao committed
Aug 29, 2026 at 08:50 UTC
b131311fb4ef7adc2752333ed7ae87182f5e2665
2 files changed
+51
-20
.github/workflows/pr-title.yml
new
+24
@@ -0,0 +1,24 @@
1
+name: PR title
2
+
3
+on:
4
+ pull_request:
5
+ types: [opened, edited, reopened, synchronize]
6
+
7
+permissions: {}
8
+
9
+jobs:
10
+ check-format:
11
+ name: Check format
12
+ runs-on: ubuntu-latest
13
+ steps:
14
+ - name: Validate title
15
+ env:
16
+ PR_TITLE: ${{ github.event.pull_request.title }}
17
+ run: |
18
+ pattern='^(\[[^][]+\])+ +[^[:space:]].*$'
19
+ if [[ "$PR_TITLE" =~ $pattern ]]; then
20
+ exit 0
21
+ fi
22
+
23
+ echo "::error::PR title must start with one or more [Tag] prefixes, followed by a space and a description."
24
+ exit 1
docs/contributing/README.md
+27
-20
@@ -221,26 +221,33 @@ AI-assisted code must meet all quality standards: proper testing, documentation,
221
222
### PR Title and Classification
223
224
-Only specific types of PRs will be reviewed. The PR title is prefixed
225
-appropriately to indicate the type of change. Please use one of the following:
226
-
227
-- `[Bugfix]` for bug fixes.
228
-- `[CI/Build]` for build or continuous integration improvements.
229
-- `[Doc]` for documentation fixes and improvements.
230
-- `[Model]` for adding a new model or improving an existing model. Model name
231
- should appear in the title.
232
-- `[Frontend]` For changes on the vLLM frontend (e.g., OpenAI API server,
233
- `LLM` class, etc.)
234
-- `[Kernel]` for changes affecting CUDA kernels or other compute kernels.
235
-- `[Core]` for changes in the core vLLM logic (e.g., `LLMEngine`,
236
- `AsyncLLMEngine`, `Scheduler`, etc.)
237
-- `[Hardware][Vendor]` for hardware-specific changes. Vendor name should
238
- appear in the prefix (e.g., `[Hardware][AMD]`).
239
-- `[Misc]` for PRs that do not fit the above categories. Please use this
240
- sparingly.
241
-
242
-!!! note
243
- If the PR spans more than one category, please include all relevant prefixes.
224
+PR titles must start with one or more bracketed tags, followed by a space and a
225
+concise description, for example, `[Bugfix][Scheduler] Fix priority handling`.
226
+Any descriptive tag is accepted. The following well-known tags improve
227
+consistency and discoverability; use one of them when it fits, or choose a more
228
+specific tag.
229
+
230
+**Type tags** describe the nature of the change:
231
+
232
+- `[Bugfix]`, `[Feature]`, `[Perf]`, and `[Refactor]` for code changes.
233
+- `[CI]` or `[CI/Build]`, `[Test]`, and `[Doc]` or `[Docs]` for project
234
+ infrastructure, tests, and documentation.
235
+- `[Misc]` when another type tag does not fit.
236
+
237
+**Scope tags** identify the affected area:
238
+
239
+- `[Model]`, `[Frontend]`, `[Rust Frontend]`, `[Core]`, and `[Kernel]` for major
240
+ areas of the codebase.
241
+- `[Model Runner V2]` or `[MRV2]`, `[Attention]`, `[Multimodal]`,
242
+ `[Quantization]`, `[MoE]`, `[Spec Decode]`, `[LoRA]`, `[KV Connector]`, and
243
+ `[KV Offload]` for frequently changed subsystems.
244
+- `[ROCm]`, `[XPU]`, `[CPU]`, or `[Hardware][Vendor]` for hardware-specific
245
+ changes. Replace `Vendor` with the vendor name, for example,
246
+ `[Hardware][AMD]`.
247
+
248
+Type and scope tags can be combined, and multiple tags from either category can
249
+be stacked without spaces. For example, `[Bugfix][KV Offload] Fix block
250
+accounting` or `[Perf][ROCm][Kernel] Optimize fused MoE`.
251
252
### Code Quality
253