Making a Pull Request (Patch Acceptance Process)

This page outlines how contributors can propose and make changes to the Bazel code base.

  1. Read the Bazel Contribution policy.
  2. Create a GitHub issue to discuss your plan and design. Pull requests that change or add behavior need a corresponding issue for tracking.
  3. If you’re proposing significant changes, write a design document.
  4. Ensure you’ve signed a Contributor License Agreement.
  5. Prepare a git commit that implements the feature. Don’t forget to add tests and update the documentation. If your change has user-visible effects, please add release notes. If it is an incompatible change, read the guide for rolling out breaking changes.
  6. Create a pull request on GitHub. If you’re new to GitHub, read about pull requests. Note that we restrict permissions to create branches on the main Bazel repository, so you will need to push your commit to your own fork of the repository.
  7. A Bazel maintainer should assign you a reviewer within two business days (excluding holidays in the USA and Germany). If you aren’t assigned a reviewer in that time, you can request one by emailing bazel-dev@googlegroups.com.
  8. Work with the reviewer to complete a code review. For each change, create a new commit and push it to make changes to your pull request. If the review takes too long (e.g. reviewer is unresponsive), send an email to bazel-dev@googlegroups.com.

  9. After the review is complete, the pull request can be finalized. Note that some repositories, such as bazel do not allow to directly merge a PR. In that case, a Bazel maintainer applies your patch to Google’s internal version control system. Only after that process is concluded, which may take more than one day, the PR will be closed automatically.

    The import to Google’s internal version control system triggers internal presubmit checks that may suggest more changes. If you haven’t expressed a preference, the maintainer submitting your change adds “trivial” changes (such as linting) that don’t affect design. If deeper changes are required or you’d prefer to apply changes directly, you and the reviewer should communicate preferences clearly in review comments.

    After internal submission, the patch is exported as a Git commit, at which point the GitHub pull request is closed. All final changes are attributed to you.