Principle:Kubeflow Kubeflow Pull Request Submission
| Knowledge Sources | |
|---|---|
| Domains | Pull Request Workflow, Code Review, CI/CD, DCO Compliance |
| Last Updated | 2026-02-13 00:00 GMT |
Overview
Pull request submission is the final stage of the contribution workflow where contributors push their code changes, sign off on the Developer Certificate of Origin, pass CI checks, and undergo code review by OWNERS-designated reviewers before merge.
Description
In the Kubeflow project, pull request submission is a structured process that combines Git-level requirements (DCO sign-off), platform-level automation (CI checks, stale bot management), and social processes (OWNERS-based code review). Every pull request must satisfy all three dimensions before it can be merged.
The Developer Certificate of Origin (DCO) is a lightweight legal framework that requires contributors to certify they have the right to submit their contribution under the project's license. This is implemented via the git commit -s flag, which appends a Signed-off-by: Name <email> line to each commit message. CI checks enforce that all commits in a PR carry this sign-off.
The OWNERS file system defines who can review and approve changes in specific directories. Each sub-project maintains OWNERS files that list reviewers (who can provide feedback) and approvers (who can authorize merge). The PR must receive approval from at least one approver listed in the relevant OWNERS file.
CI checks run automatically when a PR is created or updated. These typically include unit tests, integration tests, linting, and DCO verification. All checks must pass before the PR can be merged.
The stale bot also applies to pull requests: PRs that remain inactive for 90 days are marked stale and subject to automatic closure after a 7-day grace period, using the same configuration that governs issues. This ensures abandoned PRs do not clutter the review queue indefinitely.
Usage
Submit a pull request when:
- Code changes are complete and tested locally against the sub-project's test suite.
- All commits have been signed off with the DCO (
git commit -s). - The branch is up to date with the target branch (typically
mainormaster). - The contributor has engaged with the community (via issue comment or Slack) to signal intent for non-trivial changes.
- The PR description clearly explains what the change does, why it is needed, and how it was tested.
Theoretical Basis
The pull request submission process follows a gated merge model with multiple verification stages:
- Prepare the branch: The contributor works in a feature branch on their fork, making commits with DCO sign-off (
git commit -s). Each commit message should follow the project's convention and include theSigned-off-byline. - Push and create PR: The contributor pushes their branch to their fork and creates a pull request against the upstream sub-project repository. The PR description should include:
- A clear summary of the changes.
- References to related issues (using
Fixes #NNNorRelates to #NNN). - Testing methodology and results.
- Automated verification: CI pipelines run automatically, checking:
- DCO compliance: Every commit has a valid
Signed-off-byline. - Unit and integration tests: The code changes do not break existing functionality.
- Linting and formatting: The code adheres to project style guidelines.
- DCO compliance: Every commit has a valid
- Code review: Reviewers and approvers listed in the relevant OWNERS files examine the changes. The review focuses on correctness, design alignment, test coverage, and documentation.
- Iteration: The contributor addresses review feedback by pushing additional commits (also DCO-signed). Each push triggers a new CI run.
- Approval and merge: Once CI passes and an OWNERS-listed approver gives approval, the PR is merged. The associated issue can be automatically closed if the PR description uses
Fixes #NNNsyntax. - Stale management: If the PR becomes inactive during review (e.g., the contributor does not respond to feedback), the stale bot marks it after 90 days and closes it after 97 days total, unless it carries an exempt label.
This multi-gate approach ensures code quality while keeping the contribution process transparent and predictable.