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 main knative repo should not overlap. This simplifies promoting repos between the two orgs and setting up knative.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)

  1. (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 or README.

  2. (Requires repo write/org owner) Create:

    At the end of this step, you should have 4 files: LICENSE, OWNERS, CODE-OF-CONDUCT.md, and README.md

  3. 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)

  4. (For golang repos) Set up an alias under knative.dev to enable knative.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.

  5. Set up test-infra using the automation, which probably involves updating config/prod/prow/config_knative.yaml and then running ./hack/generate-configs.sh

  6. 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.

  7. 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