Here are the steps involved in setting up a new repository; there is more information in the sections below.
Step 1-3 should be performed by admin for the Kubeflow org
-
Create the repository
-
Configure the repository in GitHub following the instructions below
- enable branch protections
-
Create an OWNERS file at the root of the repository
- Anyone can create the PR
- PR will need to be merged manually by Kubeflow org administrator
- For more info on OWNERS files see CONTRIBUTING.md
- After the OWNERs file is merged subsequent PRs can be automatically merged by Tide
-
Setup prow for the repository by following the instructions below
- This step can be performed by anyone; doesn't need to be a Kubeflow org admin
-
Open a PR to org.yaml granting write permssion to the
ci-bots
team.
We use Prow
* Continuous integration
* Automatic merging of PRs (tide)
* Tide should automatically be enabled for all repositories in the Kubeflow org
* Manage PRs using bots
- Configure prow for the repository by following these instructions
- Create a prow_config.yaml file with the following contents
workflows: []
-
This file is sufficient to ensure the prow jobs pass but doesn't run any actual tests.
-
When you are ready to actually add E2E tests you can follow adding basic e2e tests to add a basic E2E test for your repository
-
See kubeflow/testing#11 for work creating generating tests for things like lint.
When setting up permissions for a repository there a few things to note:
-
When providing permissions for
Collaborators and teams
, only teams should be used. -
Teams that should be added by default, with write access, are
ci-bots
andcore-approvers
.- Additional teams can be added as necessary but
- Most operations should be done via the ci-bots and adding folks to the owners files
- So the number of folks with direct access to a repository should be small (<5)
Make sure to enable the third-party apps used by the Kubeflow community.
These apps include:
- Reviewable
- For Reviewable, sign in with Github and in the
Repositories
tab, make sure to allow visibility to your other orgs. After the allowingKubeflow
you should be able to enable your repo. - Click on the enabled repo in Reviewable and make sure to disable
Review status in GitHub PR
because this causes problems for prow kubernetes/test-infra#7140
- For Reviewable, sign in with Github and in the
- TravisCI
- For TravisCI, any administrator of the repo should be able to enable tests. Just follow the TravisCI Getting Started Guide.
- Coveralls
- For instructions on enabling coveralls and integrating with travis, you can follow these instructions. If you aren't an org admin, you may need to request assistance in enabling coveralls.
When setting up the repo, the master
branch should be protected. Instructions on protection a branch can be found here.
A few things to note when setting up branch protection:
- Enable
Protect this branch
to protect the code in themaster
branch. - Be sure not to enable
Require pull request reviews before merging
. This setting conflicts with Tide as seen in this issue. - Don't enable
Require branches to be up to date before merging
- Enable
Require status checks to pass before merging