How to Contribute
March 10, 2026 ยท View on GitHub
We would love to accept your patches and contributions to this project.
Before you begin
Sign our Contributor License Agreement
Contributions to this project must be accompanied by a Contributor License Agreement (CLA). You (or your employer) retain the copyright to your contribution; this simply gives us permission to use and redistribute your contributions as part of the project.
If you or your current employer have already signed the Google CLA (even if it was for a different project), you probably don't need to do it again.
Visit https://cla.developers.google.com/ to see your current agreements or to sign a new one.
Review our Community Guidelines
This project follows Google's Open Source Community Guidelines.
Contribution process
- Fork and clone the repository
- Set up Development Environment
- Make your change
- Verify change against checklist
- Open a Pull Request
1. Fork and clone the repository
All changes should be performed on your XPK fork, then proposed to the mainline repository through the pull request process. More about how to work with forks can be found here.
2. Set up Development Environment
Step 1: System and Virtual Environment Setup
Follow the Installation from Source instructions in the main guide. This will ensure you have:
- Installed all system prerequisites (Python, gcloud, etc.).
- Created and activated your Virtual Environment (required to avoid "externally managed environment" errors).
Step 2: Install XPK dev dependencies
Once your virtual environment is active, install XPK in editable mode with development dependencies:
pip install .[dev]
3. Make your change
Make your intended code change, cover it with unit tests, and iterate on the code.
To execute your local XPK version via the command line, make sure you have added the local bin directory to your path as described in the Installation from Source guide.
4. Verify change against checklist
Before opening a pull request make sure your change passes the following checklist:
- Tests: Change is covered with unit tests.
- Goldens: Goldens are up-to-date. Regenerate them using the following command:
make goldens - Feature Flags: Change is production ready. If not, make sure it is covered with a feature flag. See sample flags here.
Code merged to the main branch is expected to be released at any given point in time, hence it needs to be treated as production code.
You can read more about our testing guidance here.
5. Open a Pull Request
All submissions, including submissions by project members, require review. We use GitHub pull requests for this purpose.