Draft or submit Apache SeaTunnel pull requests in English using the repository's required title and body conventions. Use when Codex needs to prepare a PR from the current branch or diff, infer a compliant `[Type][Module][SubModule] Description` title, fill the required PR template, describe what changed from git history or file diffs, or open the PR after the user provides or omits the change summary.
Draft SeaTunnel PR titles and bodies that match the repository rules. Prefer the user's own summary of the change, then use the current branch diff to verify or complete it.
Inspect the current change set before writing anything. Prefer committed branch changes when the branch is already ahead of its base. If the user is preparing a PR before committing, inspect staged and unstaged changes and say that the draft reflects the working tree. Read the repository's current PR template before drafting the body so the generated content follows the latest sections and checklist wording.
Use non-interactive git commands such as:
git branch --show-current
git status --short
git diff --stat
git diff --name-only
git diff --cached --stat
git log --oneline -5
sed -n '1,220p' .github/PULL_REQUEST_TEMPLATE.md
If an upstream branch exists, also inspect the branch-level change set:
git log --oneline @{upstream}..HEAD
git diff --stat @{upstream}...HEAD
git diff --name-only @{upstream}...HEAD
Use the user's description as the primary explanation of intent. Use the diff only to sharpen wording, identify the correct module, and catch obvious mismatches. If the user's summary materially conflicts with the diff, pause and call out the mismatch before submitting the PR.
Write the title in English. Use one of these formats:
[Type][Module] Description[Type][Module][SubModule] DescriptionChoose Type from the dominant change:
| Signal | Type |
|---|---|
| New behavior, new option, new capability | Feature |
| Bug fix or correction | Fix |
| Optimization, cleanup, or non-breaking refinement | Improve |
| Urgent CI, dependency, or release blocker fix | Hotfix |
| Documentation-only change | Docs |
| Test-only change | Test |
| Build, tooling, or maintenance work | Chore |
Choose Module from the dominant path:
| Path pattern | Module | SubModule hint |
|---|---|---|
seatunnel-connectors-v2/... | Connector-V2 | Connector name |
seatunnel-transforms-v2/... | Transform-V2 | Transform name |
seatunnel-engine/... | Zeta | Engine area if clear |
seatunnel-core/... | Core | Omit when not needed |
seatunnel-api/... | API | Omit when not needed |
seatunnel-e2e/... | E2E | Suite or connector name |
.github/..., CI workflow files | CI | Workflow or job name |
bin/..., shell scripts | Shell | Script name |
tools/... | Tools | Tool name |
docs/... only | Docs | Usually omit submodule |
Apply these rules:
SubModule only when one connector, transform, or area clearly dominates the diff.Examples:
[Fix][Connector-V2][Milvus] Fix partition creation[Feature][Transform-V2] Support AES_GCM algorithm in FieldEncrypt[Improve][Zeta] Optimize multiple table job config parsing[Docs] Remove redundant lines from transform docsMirror the current .github/PULL_REQUEST_TEMPLATE.md headings and checklist structure, and keep the body in English.
Use the repository template as the source of truth when wording changes in the future.
At minimum, include these sections:
### Purpose of this pull request
<Explain what changed and why. Prefer 1 short paragraph or 2 flat bullets. Mention the real files, modules, or behaviors changed.>
### Does this PR introduce _any_ user-facing change?
<Write the behavior difference if users can notice it. For docs-only or internal-only changes, write `No`.>
### How was this patch tested?
<List the real verification that ran. Never claim tests that did not run. If nothing ran yet, write `Not run yet.`>
### Check list
- [ ] New dependency is documented under the New License Guide
- [ ] Documentation is updated if needed
- [ ] incompatible-changes.md is updated if needed
- [ ] Connector changes include plugin-mapping.properties, seatunnel-dist pom, CI label, E2E, and plugin_config updates if needed
Write the body from evidence:
Before claiming a PR is ready, prefer repository validation that matches the actual scope. For SeaTunnel work, the common baseline is:
./mvnw spotless:apply
./mvnw -q -DskipTests verify
./mvnw test
Use narrower verification when the change is local and the user prefers a smaller check, but never invent coverage. If validation has not happened yet, say so directly in the PR body and recommend the relevant command before opening the PR.
If the user asks to open the PR, prepare the final title and body first, then create the PR with a non-interactive flow.
Prefer the available GitHub integration.
If you fall back to gh, use a non-interactive command such as gh pr create --title ... --body-file ....
Keep these constraints:
When the user asks for a draft, return:
Title: [Type][Module][SubModule] Description
Body:
### Purpose of this pull request
...
### Does this PR introduce _any_ user-facing change?
...
### How was this patch tested?
...
### Check list
- [ ] ...
When the user also gives a manual summary, integrate it first and only use the diff to refine the title and fill in missing facts.