Welcome! If you haven't seen them already, the Kubernetes project has:
- A Contributor Guide - some kubernetes/kubernetes-specific content, but lots of info for the entire project
- A Contributor Cheat Sheet - lots of resources and handy links
This repo is owned by SIG Testing, and the people most directly involved are listed in /OWNERS. We are most responsive on our slack channel
- Community Site: kubernetes/community/sig-testing
- Slack: #sig-testing
- Mailing List: kubernetes-sig-testing@
We also have three other slack channels:
- #testing-ops: for prow.k8s.io and other test-infra ops. Ping
@test-infra-oncallor check go.k8s.io/oncall - #prow: for discussions related to the use or development of
prow - #testgrid: for discussions related to the use of development of
testgrid
In general we use the same pull request (PR) and review workflow used by the rest of the Kubernetes project. This means the use of the CNCF CLA, code review by reviewers and approvers listed in OWNERS files, and tests that automatically exercise code or enforce conventions. Many PRs will result in changes automatically being deployed.
Some conventions that are specific to this repo:
- For large code changes, please write a design doc or KEP and get signoff from SIG Testing before trying to land code. If you're not sure what a KEP should look like, kuberenetes/enhancements/keps/sig-testing has some examples. If you're not sure what "large" means, come ask us
- We find it polite to apply the
do-not-merge/holdlabel via the/holdcommand when in doubt about whether/when a PR should merge. If we don't explain why we're adding a/hold, this is usually because the PR will cause changes to be deployed on merge, and we want the person responsible for deploying and monitoring the changes to decide when to/hold cancel. In some cases this is the PR author, in other cases this may be whomever is on-call for prow.k8.io. If you are unsure which, please ask. - Many of us use gubernator.k8s.io/pr to keep track of which PRs require
our attention. Use of the
/cc @personor/assign @personcommands is the most effective way to put PRs on our radar. You can also contact us on slack.
Issues are ideally labeled with:
- milestone: during which release cycle do we plan on working on this issue
sig/foo: which SIG owns this workarea/foo: which subproject or code is this issue related tokind/foo: which kind of work is this issue describingpriority/foo: how important is this issue
For example, an issue related to cleaning up and consolidating (kind/cleanup)
release-related (sig/release) jobs and dashboards (area/config) for the
v1.16 cycle (milestone: v1.16) that may not get completed by the end of the
cycle if more important or more urgent arises (priority/important-longterm).
We try to have a non-stale pool of issues that are available for new contributors who want to help out but aren't sure what to work on or where to get started:
label:"good first issue"- triaged per Good First Issue docslabel:"help wanted"- triaged per Help Wanted docs
If you're not sure where to contribute or what any of these mean, please see /README.md for a brief description of the various codebases in this repo.
We use make rules to build, test and deploy code in this repo. In most cases you can get by just fine with:
make test
Please see /docs/dep.md
The majority of the Kubernetes project is tested via prowjobs that run on prow.k8s.io. See /config/jobs/README.md for more information.
Test results generated by our prow jobs are available at testgrid.k8s.io. To learn more about how to configure which test results display where, see /testgrid/README.md
go.k8s.io/github-labels describes GitHub labels that are synced across all Kubernetes orgs and repos. To update these, please see /label_sync/README.md
We welcome contribution of e2e test results for kubernetes/kubernetes generated by other CI systems on other platforms to ensure that Kubernetes has test coverage in a variety of environments. For more info please see /docs/contributing-test-results.md