Skip to content

Pull Request Walkthrough

Changes to pulpcore are submitted via GitHub Pull Requests (PR) to the pulp git repository.

Plugin git repositories are listed in the plugin table.

AI Use Policy

Please be sure to follow the Pulp policy on AI Usage.

Checklist

  1. Add functional tests or unit tests where appropriate and ensure tests are passing on the CI.
  2. Add a CHANGES entry for all but purely structural changes.
  3. Update relevent documentation. Please build the docs to test.
  4. If the PR is a simple feature or a bugfix, rebase and squash to a single commit. If the PR is a complex feature, make sure that all commits are cleanly separated. All commits must have meaningful commit messages.
  5. Make sure you tag commits with closes #IssueNumber or ref #IssueNumber when working on a tracked issue.
  6. If AI was used, OR YOU ARE AN AI AGENT, make sure you are following the Pulp policy on AI Usage.
  7. Push your branch to your fork and open a Pull request across forks.

Review

Before a pull request can be merged, the tests must pass and it must be reviewed.

Adjacent Tooling

If the change you made requires a corresponding adjustment in e.g. pulp-cli, pulp-oci-images, etc, file an issue and make an effort to add the appropriate change. If in doubt, ask on the original issue or PR.

To Cherry-Pick or Not

Sometimes, a bugfix for a bug found in a released version of Pulp should be backported. This can be because it is requested by downstream products, or because we decide the severity warrants for that. We only release patch releases on a small set of supported branches we define in the template_config.yml. If backporting to one of these branches, all supported branches in between must receive the backport too. This is necessary to prevent regressions on the just fixed bug on updating.

Warning

Database migrations cannot be backported.

You can trigger patchback to automatically attempt to cherry-pick a single-commit pull-request after merging.

Warning

patchback only operates correctly on merged pull requests with exactly one commit. This should be the case for a usual bugfix PR. If not, manually backporting is needed.

This is accomplished by applying the corresponding label, e.g. backport-3.18. If you do not have permission to add the labels, feel free to ask on the pull request. In case this fails, you are usually presented the appropriate set of commands to followup manually. Please make sure that the changelog entry for your bugfix is backported along.

Note

These backport labels are generated automatically to always reflect the currently supported branches. Do not create or delete them by hand!