You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .claude/skills/be-code-style/SKILL.md
+9Lines changed: 9 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,6 +14,14 @@ Fix C++ code formatting issues in the BE and Cloud modules using the project's c
14
14
- When CI reports clang-format failures
15
15
- When you need to check or fix C++ code style
16
16
17
+
## Prerequisites
18
+
19
+
You need to confirm that the major version of the called clang-format is 16. If the current environment's default does not meet this requirement, try the following:
20
+
21
+
1. If `.vscode/settings.json` exists, use the clang-format.executable item in it.
22
+
2. If it is a worktree directory, use the `.vscode/settings.json` from the main directory.
23
+
3. Check the path to the compiler toolchain by trying to find it from the `PATH` environment variable, the current directory, and the main directory's `custom_env.sh`. Look for a clang-format with the major version number 16 in that path and its parent directory.
24
+
17
25
## Procedure
18
26
19
27
### Step 1: Auto-fix formatting
@@ -53,6 +61,7 @@ After running `clang-format.sh`, review the changes with `git diff` to verify on
53
61
## Excluded Directories
54
62
55
63
The following are excluded from formatting (see `.clang-format-ignore`):
Copy file name to clipboardExpand all lines: AGENTS.md
+12-2Lines changed: 12 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,6 +2,10 @@
2
2
3
3
This is the codebase for Apache Doris, an MPP OLAP database. It primarily consists of the Backend module BE (`be/`, execution and storage engine), the Frontend module FE (`fe/`, optimizer and transaction core), and the Cloud module (`cloud/`, storage-compute separation). Your basic development workflow is: modify code, build using standard procedures, add and run tests, and submit relevant changes.
4
4
5
+
## Security Threat Model
6
+
7
+
For security scans, vulnerability triage, security reviews, and changes involving authentication, authorization, network boundaries, external catalogs, cloud tenancy, or other security-sensitive behavior, read `threat-model.md` first. Use it to determine in-scope components, trust boundaries, attacker roles, explicit non-goals, and triage classification. Findings that are out of model or by design under `threat-model.md` should be reported as such, not treated as Doris vulnerabilities.
8
+
5
9
## When running in a WORKTREE directory
6
10
7
11
To ensure smooth test execution without interference between worktrees, the first thing to do upon entering a worktree directory is to check if `.worktree_initialized` exists. If not, execute `hooks/setup_worktree.sh`, setting `$ROOT_WORKSPACE_PATH` to the base directory (typically `${DORIS_REPO}`) beforehand. After successful execution, verify that `.worktree_initialized` has been touched and that `thirdparty/installed` dependencies exist correctly. Also check if submodules have been properly initialized; if not, do so manually.
@@ -12,6 +16,8 @@ When working in worktree mode, all operations must be confined to the current wo
12
16
13
17
Assert correctness only—never use defensive programming with `if` or similar constructs. Any `if` check for errors must have a clearly known inevitable failure path (not speculation). If no such scenario is found, strictly avoid using `if(valid)` checks. However, you may use the `DORIS_CHECK` macro for precondition assertions (if inside performance-sensitive areas like loops, it can only be `DCHECK`). For example, if logically A=true should always imply B=true, then strictly avoid `if (A && B)` and instead use `if (A) { DORIS_CHECK(B); ... }`. In short, the principle is: upon discovering errors or unexpected situations, report errors or crash—never allow the process to continue.
14
18
19
+
For `PaddedPODArray` and its peripheral packaging types, such as some certain Column, negative alignment allows the use of -1 as a valid index. No additional special handling is needed when the index may be -1.
20
+
15
21
When adding code, strictly follow existing similar code in similar contexts, including interface usage, error handling, and locking patterns. When adding any code, first try to reference existing functionality. Second, examine the relevant context paragraphs to fully understand the logic.
16
22
17
23
After adding code, conduct self-review and refactoring attempts to ensure good abstraction and reuse as much as possible.
@@ -35,7 +41,7 @@ When conducting code review (including self-review and review tasks), complete t
35
41
Always use only the `build.sh` script with its correct parameters to build Doris BE and FE. For example, the simplest BE+FE build command is `./build.sh --be --fe`.
36
42
Build type can be set via `BUILD_TYPE` in `custom_env.sh`, but only set it to `RELEASE` when explicitly required for performance testing; otherwise, keep it as `ASAN`.
37
43
You may modify BE and FE ports and network settings in `conf/` before compilation to ensure correctness and avoid conflicts.
38
-
Build artifacts are in the current directory's `output/`. If starting the service, ensure all process artifacts have their conf set with appropriate non-conflicting ports and `priority_networks = 10.16.10.3/24`. Use `--daemon` when starting. Cluster startup is slow; wait at least 30s for success. If still not ready after waiting, continue waiting. If not ready after a long time, check BE and FE logs to investigate.
44
+
Build artifacts are in the current directory's `output/`. If starting the service, ensure all process artifacts have their conf set with appropriate non-conflicting ports and the correct `priority_networks` that match the current network environment, for example `priority_networks = 10.16.10.3/24`. Use `--daemon` when starting. Cluster startup is slow; wait at least 30s for success. If still not ready after waiting, continue waiting. If not ready after a long time, check BE and FE logs to investigate.
39
45
For first-time cluster startup, you may need to manually add the backend.
40
46
41
47
## Testing Standards
@@ -47,11 +53,13 @@ You must use the preset scripts in the codebase with their correct parameters to
47
53
Key utility functions in BE code, as well as the core logic of complete features, must have corresponding unit tests. If it is inconvenient to add unit tests, revisit the module design and function decomposition to ensure high cohesion and low coupling.
48
54
49
55
Added regression tests must comply with the following standards:
56
+
50
57
1. Use `order_qt` prefix or manually add `order by` to ensure ordered results
51
58
2. For cases expected to error, use the `test{sql,exception}` pattern
52
59
3. After completing tests, do not drop tables; instead drop tables before using them in tests, to preserve the environment for debugging
53
60
4. For ordinary single test tables, do not use `def tableName` form; instead hardcode your table name in all SQL
54
61
5. Except for variables you explicitly need to adjust for testing current functionality, other variables do not need extra setup before testing. For example, nereids optimizer and pipeline engine settings can use default states
62
+
6. For determined expected results, do not using methods like `assert` in test groovy files, but instead generate the `.out` file using `qt_sql` and similar methods.
55
63
56
64
## Commit Standards
57
65
@@ -83,10 +91,12 @@ Problem Summary: <Describe the problem this commit addresses>
83
91
```
84
92
85
93
Key rules for commit messages:
94
+
86
95
1. The title must follow the `[type](module)` format validated by the PR title checker (`.github/workflows/title-checker.yml`). Common types include: `fix`, `feature`, `improvement`, `refactor`, `chore`, `test`, `doc`. Common modules include: `fe`, `be`, `cloud`, `regression`, `build`
87
96
2. The short summary must be concise and written in imperative mood (e.g., `[fix](fe) Fix null pointer in scan node` not `[fix](fe) Fixed null pointer`)
88
97
3. The `Issue Number` field must reference the corresponding GitHub Issue with `close #xxx` syntax when applicable
89
98
4. The `Release note` section must be filled in for any user-visible behavior or feature change; write "None" for internal refactoring or test-only changes
90
-
5. The test section must honestly reflect the testing performed; do not claim tests that were not actually run
99
+
5. The `Problem Summary` section should cover the following content when available: problem reproduction method, root cause in code, end-to-end results/phenomena before and after repair, and the fix. If it's a refactoring, explain the reason. If it's a performance improvement, specify the case and the exact improvement amount. DO NOT mention any specific JIRA numbers. The background of the problem should be fully understandable through this section alone.
100
+
6. The test section must honestly reflect the testing performed; do not claim tests that were not actually run
91
101
92
102
Files in a git commit should only be related to the current modification task. Environment modifications for running (for example `conf/`, `AGENTS.md`, `hooks/`) must not be `git add`ed. When delivering the final task, ensure all actual code modifications have been committed.
0 commit comments