Skip to content

contributing.md

Latest commit

 

History

History
87 lines (55 loc) · 3.77 KB

contributing.md

File metadata and controls

87 lines (55 loc) · 3.77 KB

How to Contribute

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

  1. Fork and clone the repository
  2. Set up Development Environment
  3. Make your change
  4. Verify change against checklist
  5. 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.