We use analytics and cookies to understand site traffic. Information about your use of our site is shared with Google for that purpose. Learn more.
Creating a sandbox repo
Background
The knative-sandbox
GitHub org exists to
hold “non-core” Knative components which are owned and sponsored by a Working
Group. See the Knative Repository Guidelines for
more details on the requirements for the knative-sandbox
org.
Criteria
A Working Group Lead (either
technical or
execution) may request a new repo in
knative-sandbox
by filing an issue in the
knative/community
repo. Once filed, the TOC should handle these promptly, though it should also be
considered fine to ping members or the group on Slack if it hasn’t been acted on
in a few days. Generally, the request will be granted, though the TOC may have
additional questions or suggest an alternate mechanism in some cases.
Some of the following steps may require permissions that are only available to the TOC or Steering Committee, though others are largely self-service or require other WGs to review and approve impacting changes.
Technical requirements
-
Any contributed code should be contributed by the original authors or copyright holders under an Apache 2.0 license. See also this section of the repository guidelines.
-
Names between
knative-sandbox
and the mainknative
repo should not overlap. This simplifies promoting repos between the two orgs and setting upknative.dev
import paths for golang. -
Prow automation for tests is encouraged but not required for
knative-sandbox
, but the Google CLA bot and OWNERS files/tide merge should be enforced.
Process (to be executed by TOC or Steering member)
-
(Requires Org owner) Create the new repo in https://github.com/knative-sandbox using the “New” button. Set the repo to public and include an “Apache License 2.0” but no
.gitignore
orREADME
. -
(Requires repo write/org owner) Create:
-
OWNERS
file listing TOC and WG members as approvers, and WG members as reviewers -
CODE-OF-CONDUCT.md
(that links to https://github.com/knative/community/blob/master/CODE-OF-CONDUCT.md) -
README.md
for the repo by cloning it and pushing directly to the repo.
At the end of this step, you should have 4 files:
LICENSE
,OWNERS
,CODE-OF-CONDUCT.md
, andREADME.md
-
-
Add entries for the repo to
../peribolos/knative-sandbox.yaml
in knative/community. As part of this, grant one or more sponsoring WGs the “write” permission on the repo (sample PR) -
(For golang repos) Set up an alias under
knative.dev
to enableknative.dev/
golang imports by adding a file for the repo to https://github.com/knative/website/tree/master/static/golang and updating the_redirects
file. -
Set up test-infra using the automation, which probably involves updating
config/prod/prow/config_knative.yaml
and then running./hack/generate-configs.sh
-
Ensure that Prow is working correctly by creating a PR against the repo. One good way to do this is to add a
test/presubmit-tests.sh
via either the web UI or using a fork. -
Once at least one PR has been created, you’ll be able to select the branch protection checks which are required in the “Settings” > “Branches” branch protection rule:
- Under “Branches” add a branch protection rule for
master
:- Require status checks to pass (except
...-go-coverage
checks) - Include administrators
- Require status checks to pass (except
- Under “Branches” add a branch protection rule for
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.