Skip to main content
Version: v3.15.x

How to contribute

Thanks for your interest in contributing to the Gatekeeper project! This document will help answer common questions you may have during your contribution.

Where to start?

Join us to help define the direction and implementation of this project!

Contributing Process

Please follow these 3 steps for contributions:

  1. Commit changes to a git branch in your fork, making sure to sign-off those changes for the Developer Certificate of Origin.
  2. Create a GitHub Pull Request for your change, following the instructions in the pull request template and use semantic PR title
  3. Perform a Pull Request Review with the project maintainers on the pull request.

Developer Certification of Origin (DCO)

This project requires contributors to sign a DCO (Developer Certificate of Origin) to ensure that the project has the proper rights to use your code.

The DCO is an attestation attached to every commit made by every developer. In the commit message of the contribution, the developer simply adds a Signed-off-by statement and thereby agrees to the DCO, which you can find at

DCO Sign-Off via the command line

Configure your local git to sign off your username and email address that is associated with your GitHub user account.

$ git config --global "John Doe" 
$ git config --global

Then, for every commit, add a signoff statement via the -s flag.

$ git commit -s -m "This is my commit message"

If you forget to add the sign-off you can also amend a previous commit with the sign-off by running git commit --amend -s. If you've pushed your changes to GitHub already you'll need to force push your branch with git push -f.

Pull Request Review Process

Please take a look at this article if you're not familiar with GitHub Pull Requests.

Once you open a pull request, project maintainers will review your changes and respond to your pull request with any feedback they might have.

Pull Request Test Requirements

For code updates, to ensure high quality commits, we require that all pull requests to this project meet these specifications:

  1. Tests: We require all the code in Gatekeeper to have at least unit test coverage.
  2. Green CI Tests: We require these test runs to succeed on every pull request before being merged.

Optional benchmarking of changes

To ensure that any changes made to the code do not negatively impact its performance, you can run benchmark tests on the changes included in a pull request. To do this, simply comment /benchmark on the pull request. This will trigger the benchmark tests to run on both the current HEAD and the code changes in the pull request. The results of the benchmark tests will then be commented on the pull request using benchstat.

If you are introducing a new feature, doing a big refactor, or fixing a critical bug, it's especially important to run benchmark tests on the changes you are trying to merge. This will help ensure that the changes do not negatively impact the performance of the code and that it continues to function as expected.

Below is the sample output that will be commented on the pull request:

name                                              old time/op  new time/op  delta goos:linux goarch:amd64
System_Mutate 1.48µs ± 5% 1.50µs ± 4% ~ (p=0.468 n=10+10) goos:linux goarch:amd64
AssignMutator_Mutate/always_mutate_1-depth 235ns ± 5% 234ns ± 5% ~ (p=0.726 n=10+10)
AssignMutator_Mutate/always_mutate_2-depth 287ns ± 6% 279ns ± 5% ~ (p=0.190 n=10+10)
AssignMutator_Mutate/always_mutate_5-depth 420ns ± 2% 416ns ± 3% ~ (p=0.297 n=9+9)
AssignMutator_Mutate/always_mutate_10-depth 556ns ± 4% 570ns ± 6% ~ (p=0.123 n=10+10)
AssignMutator_Mutate/always_mutate_20-depth 977ns ± 3% 992ns ± 2% ~ (p=0.063 n=10+10)
AssignMutator_Mutate/never_mutate_1-depth 196ns ± 4% 197ns ± 6% ~ (p=0.724 n=10+10)
AssignMutator_Mutate/never_mutate_2-depth 221ns ± 4% 222ns ± 4% ~ (p=0.971 n=10+10)
AssignMutator_Mutate/never_mutate_5-depth 294ns ± 4% 296ns ± 4% ~ (p=0.436 n=10+10)
AssignMutator_Mutate/never_mutate_10-depth 424ns ± 2% 425ns ± 3% ~ (p=0.905 n=9+10)
AssignMutator_Mutate/never_mutate_20-depth 682ns ± 3% 680ns ± 5% ~ (p=0.859 n=9+10) goos:linux goarch:amd64
AssignImageMutator_Mutate/always_mutate_1-depth 579ns ± 7% 573ns ± 3% ~ (p=0.650 n=9+9)
AssignImageMutator_Mutate/always_mutate_2-depth 625ns ± 5% 627ns ± 2% ~ (p=0.536 n=10+9)
AssignImageMutator_Mutate/always_mutate_5-depth 758ns ± 5% 768ns ± 6% ~ (p=0.631 n=10+10)
AssignImageMutator_Mutate/always_mutate_10-depth 1.06µs ± 8% 1.08µs ± 5% ~ (p=0.143 n=10+10)
AssignImageMutator_Mutate/always_mutate_20-depth 1.38µs ± 3% 1.42µs ± 3% +2.80% (p=0.003 n=9+10)
AssignImageMutator_Mutate/never_mutate_1-depth 237ns ± 3% 233ns ± 3% ~ (p=0.107 n=10+9)
AssignImageMutator_Mutate/never_mutate_2-depth 266ns ± 4% 266ns ± 3% ~ (p=1.000 n=10+10)
AssignImageMutator_Mutate/never_mutate_5-depth 336ns ± 6% 342ns ± 2% +1.85% (p=0.037 n=10+9)
AssignImageMutator_Mutate/never_mutate_10-depth 463ns ± 3% 479ns ± 5% +3.53% (p=0.013 n=9+10)
AssignImageMutator_Mutate/never_mutate_20-depth 727ns ± 3% 727ns ± 2% ~ (p=0.897 n=10+8)

If a significantly positive increase in the delta occurs, it could suggest that the changes being implemented have a negative impact on the respective package. However, there might be cases where the delta may be higher even without significant changes. In such situations, it is advisable to rerun the benchmarks for more precise and accurate results.

Contributing to Docs

If you want to contribute to docs, Gatekeeper auto-generates versioned docs. If you have any doc changes for a particular version, please update in website/docs as well as in website/versioned_docs/version-vx.y.z directory. If the change is for next release, please update in website/docs, then the change will be part of next versioned doc when we do a new release.

Contributing to Helm Chart

If you want to contribute to Helm chart, Gatekeeper auto-generates versioned Helm charts from static manifests. If you have any changes in charts directory, they will get clobbered when we do a new release. The generator code lives under cmd/build/helmify. To make modifications to this template, please edit kustomization.yaml, kustomize-for-helm.yaml and replacements.go under that directory and then run make manifests to generate changes in the manifest_staging directory. You should push all the modified files to your PR. Once it's merged, the changes will be promoted to the root charts directory the next time a Gatekeeper release is cut.

Contributing to Code

If you want to contribute code, check out the Developers guide to get started.

Contributing Templates

If you'd like to contribute a Constraint Template to the Gatekeeper Policy Library, you can find documentation on how to do that here in the library's README.