Thanks for taking the time to join our community and start contributing. These guidelines will help you get started with the Contour project. Please note that we require DCO sign off.
Read this document for additional website specific guildlines: Site Contribution Guidelines. Guidelines in this document still apply to website contributions.
If you want to get more insight into how the Contour maintainer team approaches R&D, this page captures how we work on Contour.
This section describes how to build Contour from source.
-
Install Go
Contour requires Go 1.16 or later. We also assume that you're familiar with Go's
GOPATHworkspace convention, and have the appropriate environment variables set.
Contour uses go modules for dependency management.
go get github.com/projectcontour/contour
Go is very particular when it comes to the location of the source code in your $GOPATH.
The easiest way to make the go tool happy is to rename Contour's remote location to something else, and substitute your fork for origin.
For example, to set origin to your fork, run this command substituting your GitHub username where appropriate.
git remote rename origin upstream
git remote add origin [email protected]:davecheney/contour.git
This ensures that the source code on disk remains at $GOPATH/src/github.com/projectcontour/contour while the remote repository is configured for your fork.
The remainder of this document assumes your terminal's working directory is $GOPATH/src/github.com/projectcontour/contour.
To build Contour, run:
make
This uses a go install and produces a contour binary in your $GOPATH/bin directory.
Once you have Contour building, you can run all the unit tests for the project:
make check
This assumes your working directory is set to $GOPATH/src/github.com/projectcontour/contour.
To run the tests for a single package, change to package directory and run:
go test .
Before making a commit, it's always a good idea to check the code for common programming mistakes, misspellings and other potential errors. The lint checks can be run by invoking the make lint task:
make lintNote: The lint tasks require the codespell application. Be sure to install version 2.0 or newer before running the lint tasks.
This section describes the process for contributing a bug fix or new feature. It follows from the previous section, so if you haven't set up your Go workspace and built Contour from source, do that first.
This project operates according to the talk, then code rule. If you plan to submit a pull request for anything more than a typo or obvious bug fix, first you should raise an issue to discuss your proposal, before submitting any code.
Depending on the size of the feature you may be expected to first write a design proposal. Follow the Proposal Process documented in Contour's Governance.
- Have a short subject on the first line and a body. The body can be empty.
- Use the imperative mood (ie "If applied, this commit will (subject)" should make sense).
- There must be a DCO line ("Signed-off-by: David Cheney [email protected]"), see DCO Sign Off below.
- Put a summary of the main area affected by the commit at the start, with a colon as delimiter. For example 'docs:', 'internal/(packagename):', 'design:' or something similar.
- Do not merge commits that don't relate to the affected issue (e.g. "Updating from PR comments", etc). Should the need to cherrypick a commit or rollback arise, it should be clear what a specific commit's purpose is.
- If main has moved on, you'll need to rebase before we can merge, so merging upstream main or rebasing from upstream before opening your PR will probably save you some time.
Pull requests must include a Fixes #NNNN or Updates #NNNN comment.
Remember that Fixes will close the associated issue, and Updates will link the PR to it.
<packagename>: <imperative mood short description>
<longer change description/justification>
Updates #NNNN
Fixes #MMMM
Signed-off-by: Your Name <[email protected]>
internal/contour: Add quux functions
To implement the quux functions from #xxyyz, we need to
florble the greep dots, then ensure that the florble is
warbed.
Fixes #xxyyz
Signed-off-by: Your Name <[email protected]>
Maintainers should prefer to merge pull requests with the Squash and merge option. This option is preferred for a number of reasons. First, it causes GitHub to insert the pull request number in the commit subject which makes it easier to track which PR changes landed in. Second, it gives maintainers an opportunity to edit the commit message to conform to Contour standards and general good practice. Finally, a one-to-one correspondence between pull requests and commits makes it easier to manage reverting changes and increases the reliability of bisecting the tree (since CI runs at a pull request granularity).
At a maintainer's discretion, pull requests with multiple commits can be merged with the Create a merge commit option. Merging pull requests with multiple commits can make sense in cases where a change involves code generation or mechanical changes that can be cleanly separated from semantic changes. The maintainer should review commit messages for each commit and make sure that each commit builds and passes tests.
Naming is one of the most difficult things in software engineering. Contour uses the following pattern to name imports when referencing packages from other packages.
thing_version: The name+package path of the thing and then the version separated by underscores
Examples:
contour_api_v1 "github.com/projectcontour/contour/apis/projectcontour/v1"
contour_api_v1alpha1 "github.com/projectcontour/contour/apis/projectcontour/v1alpha1"
envoy_v3 "github.com/projectcontour/contour/internal/envoy/v3"
xdscache_v3 "github.com/projectcontour/contour/internal/xdscache/v3"
Before a change is submitted it should pass all the pre commit CI jobs. If there are unrelated test failures the change can be merged so long as a reference to an issue that tracks the test failures is provided.
Once a change lands in main it will be built and available at this tag, docker.io/projectcontour/contour:main.
You can read more about the available contour images in the tagging document.
To build an image of your change using Contour's Dockerfile, run these commands (replacing the repository host and tag with your own):
docker build -t docker.io/davecheney/contour:latest .
docker push docker.io/davecheney/contour:latest
or, you can use the make helper, like so:
REGISTRY=docker.io/davecheney VERSION=latest make push
This will push to :latest in docker.io/davecheney obviously you'll also need to replace the repo host with your own here too. If you don't specify VERSION, make push will push to a git hash tag (the output of git rev-parse --short=8 --verify HEAD).
To verify your change by deploying the image you built, take one of the deployment manifests, edit it to point to your new image, and deploy to your Kubernetes cluster.
This section provides some useful information and guidelines for working with Contour's tests.
- Kubernetes Config:
HTTPProxy,Ingressor Gateway API config that Contour watches and converts to Envoy config. - DAG: The internal Contour representation of L7 proxy concepts. Kubernetes config is first converted to DAG objects before being converted to Envoy config.
- Envoy Config: Configuration that can be provided to Envoy via xDS. This is Contour's final output, generated directly from the DAG.
- Unit Test: A Go test for a particular function/package. In some cases, these test more than one package at a time.
- Feature Test: A Go test in
internal/featureteststhat tests the translation of Kubernetes config to Envoy config, using a Contour event handler and xDS server. - Integration Test: A YAML/rego test in
_integration/testsuitethat performs a full end-to-end test of Contour running in a cluster. Typically verifies the behavior of HTTP requests given a Kubernetes config (currentlyHTTPProxyand Gateway API configs have test cases).
The following table describes the major test suites covering the core Contour processing pipeline (Kubernetes config -> DAG -> Envoy config). In general, changes to the core processing pipeline should be accompanied by new/updated test cases in each of these test suites.
| Test Suite | Description |
|---|---|
internal/dag/builder_test.go (specifically TestDAGInsert* functions) |
Tests conversion of Kubernetes config to DAG objects. |
internal/dag/status_test.go |
Tests invalid Kubernetes (HTTPProxy) configs, verifying their status/conditions. |
internal/envoy/v3/*_test.go |
Tests conversion of DAG objects to Envoy config. |
internal/xdscache/v3/*_test.go (specifically the Test[Cluster|Listener|Route|Secret]Visit functions) |
Tests conversion of Kubernetes config to Envoy config. |
internal/featuretests/v3/*_test.go |
Tests conversion of Kubernetes config to Envoy config, using a ~full Contour event handler and xDS server. |
_integration/testsuite/[httpproxy|gatewayapi] |
E2E tests with Contour running in a cluster. Verifies behavior of HTTP requests for configured proxies. |
All authors to the project retain copyright to their work. However, to ensure that they are only submitting work that they have rights to, we are requiring everyone to acknowledge this by signing their work.
Since this signature indicates your rights to the contribution and certifies the statements below, it must contain your real name and email address. Various forms of noreply email address must not be used.
Any copyright notices in this repository should specify the authors as "The project authors".
To sign your work, just add a line like this at the end of your commit message:
Signed-off-by: David Cheney <[email protected]>
This can easily be done with the --signoff option to git commit.
By doing this you state that you can certify the following (from https://developercertificate.org/):
Developer Certificate of Origin
Version 1.1
Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129
Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.