All contributions to the repository must be submitted under the terms of the Apache Public License 2.0.
By contributing to this project, you agree to the Developer Certificate of Origin (DCO). This document was created by the Linux Kernel community and is a simple statement that you, as a contributor, have the legal right to make the contribution. See the DCO file for details.
All Go code is formatted with go fmt among other tools. In the root of the repository, you may run make fmt to
automatically run the formatting tools that are required.
Some formatting issues cannot be automatically fixed and these issues are flagged by various linters. You may run
make lint in the root of the repository to find any linting errors.
The linters are run on every pull-request.
All new code must contain unit tests whenever possible. If the code change is not unit testable, an integration test
must be added. These live in the test/e2e directory of the repository and are executed against a running instance of
the component in a Kind cluster.
Both unit and integration tests are run on every pull-request.
All commit messages must conform to the standards in the Kubernetes commit message guidelines.
In addition, the GitHub issue that the issue relates to should be linked at the bottom of the commit message.
You must also sign off your commit to state that you certify the DCO. To certify your commit for DCO, add a line like the following at the end of your commit message:
Signed-off-by: John Smith <john@example.com>
This can be done with the --signoff option to git commit. See the
Git documentation for details.
A commit must encompass only one "logical" change. For example, if a pull-request (PR) fixes a bug but also resolves an unrelated CI failure, that PR should contain two commits. This is so that the Git history clearly describes what each change is and why. Additionally, it makes it easier to revert changes since reverting a commit only would revert a single "logical" change.
Start by filing a GitHub issue describing the bug or feature if one doesn't already exist. If the change is a feature, please also create a design document in the enhancements repository in the enhancements/sig-policy directory. One of the maintainers listed in the OWNERS file will review the design document.
Then proceed by creating a pull-request (PR). Please make sure you follow the commit guidelines described in this document. Once the PR is created, Prow (CI tool) will automatically prompt maintainers to review the PR based on the list in the "OWNERS" file at the root of the repository.
Once the PR is approved, Prow will merge the PR.
For more details on how the code review process works with Prow, you may read the Kubernetes code review process.
All design document PRs and PRs that add new functionality must have at least two approvals from the Policy SIG,
excluding the PR author, before being merged. Note that you'll need to comment with /hold to avoid Prow from merging
the PR after a single approval.
All other PRs can be merged with one approval from the Policy SIG.