- HTTPProxy Fundamentals
- Virtual Hosts
- Inclusion and Delegation
- TLS Termination
- Upstream TLS
- Request Routing
- External Service Routing
- Request Rewriting
- Upstream Health Checks
- Client Authorization
- TLS Delegation
- Rate Limiting
- Annotations Reference
- API Reference
- Deployment Options
- Contour Configuration
- Upgrading Contour
- Enabling TLS between Envoy and Contour
- Redeploy Envoy
- AWS with NLB
- External Authorization
- JSON logging
- Migrating to HTTPProxy
- Prometheus Metrics
- PROXY Protocol Support
- Resource Limits
- Envoy Administration Access
- Contour Debug Logging
- Envoy Debug Logging
- Visualize the Contour Graph
- Show Contour xDS Resources
- Profiling Contour
- Contour Operator
- Support Policy
- Compatibility Matrix
- Contour Deprecation Policy
- Release Process
- Frequently Asked Questions
This document outlines how we use GitHub.
Contour attempts to ship on a monthly-ish, generally every four to six weeks, basis. These releases are tracked with a milestone. The current release is the milestone with the closest delivery date.
Issues which are not assigned to the current milestone should not be worked on.
This project has three levels of priority:
- p0 - Must fix immediately. This is reserved for bugs and security issues. A milestone cannot ship with open p0 issues.
- p1 - Should be done. p1 issues assigned to a milestone should be completed during that milestone.
- p2 - May be done. p2 issues assigned to a milestone may be completed during that milestone if time permits.
Issues without a priority are unprioritised. Priority will be assigned by a PM or release manager during issue triage.
We encourage support questions via issues.
Questions will be tagged
question and are not assigned a milestone or a priority.
Waiting for information
Any issue which lacks sufficient information for triage will be tagged
Issues with this tag may be closed after a reasonable length of time if further information is not forthcoming.
Issues without tags have not be triaged.
During issue triage, usually by a project member, release manager, or pm, one or more tags will be assigned.
Needs-Productindicates the issue needs attention by a product owner or PM.
Needs-design-docindicates the issue requires a design document to be circulated.
These are blocking states, these labels must be resolved, either by PM or agreeing on a design.
Assigning an issue
Issues within a milestone should be assigned to an owner when work commences on them. Assigning an issue indicates that you are working on it.
Before you start to work on an issue you should assign yourself. From that point onward you are responsible for the issue and you are expected to report timely status on the issue to anyone that asks.
If you cease work on an issue, even if incomplete, you should leave a comment to that effect on the issue and remove yourself as the assignee. From that point onward you are no longer responsible for the issue, however you may be approached as a subject matter expert–as the last person to touch the issue–by future assignees.
For infrequent contributors who are not members of the Contour project, assign yourself by leaving a comment to that effect on the issue.
Do not hoard issues, you won’t enjoy it
Requesting a review
PRs which are related to issues in the current milestone should be assigned to the current milestone. This is an indicator to reviewers that the PR is ready for review and should be reviewed in the current milestone. Occasionally PRs may be assigned to the next milestone indicating they are for review at the start of the next development cycle.
All PRs should reference the issue they relate to either by one of the following;
Fixes #NNNNindicating that merging this issue will fix issue #NNNN
Updates #NNNNindicating that merging this issue will progress issue #NNNN to some degree.
If there is no
Fixes line in the PR the review will, with the exception of trivial or self evident fixes, be deferred.
Help wanted and good first issues
help wanted and
good first issue tags may be assigned to issues in the current milestone.
To limit the amount of work in progress,
help wanted and
good first issue should not be used for issues outside the current milestone.