Merge pull request #3782 from nikhita/template-repo
Update repo creation process to use GitHub repo templates
This commit is contained in:
Kubernetes Prow Robot
GitHub
commit
399ea79a7c
|
|
@ -22,12 +22,8 @@ against the kubernetes/org repo.
|
|||
- [Core Repositories](#core-repositories)
|
||||
* [Goals](#goals-2)
|
||||
* [Rules](#rules-1)
|
||||
- [Creating Repositories](#creating-repositories)
|
||||
* [Non-staging repositories](#non-staging-repositories)
|
||||
* [Staging repositories](#staging-repositories)
|
||||
- [Removing Repositories](#removing-repositories)
|
||||
* [Grounds for removal](#grounds-for-removal)
|
||||
* [Procedure for removal](#procedure-for-removal)
|
||||
- [FAQ](#faq)
|
||||
|
||||
## Associated Repositories
|
||||
|
|
@ -137,64 +133,6 @@ ecosystem. Carries the endorsement of the Kubernetes community.
|
|||
Kubernetes steering committee elections. in the Kubernetes community
|
||||
* Repository must be approved by SIG-Architecture
|
||||
|
||||
## Creating Repositories
|
||||
|
||||
### Non-staging repositories
|
||||
|
||||
For non-staging repositories, suggestions on how to create
|
||||
a new repository are described below.
|
||||
|
||||
* Ensure that the repo creation request has appropriate approvals
|
||||
as per the rules mentioned above.
|
||||
* Using the organization and repository name mentioned in the repo creation
|
||||
request, create a new repo with default GitHub settings.
|
||||
* Set the description as per the repo creation request.
|
||||
* Clone the newly created repo locally.
|
||||
* Copy the latest contents of [kubernetes-template-project] and create an
|
||||
initial commit with the message *Initial commit from the
|
||||
kubernetes-template-project*.
|
||||
* Make the following changes in the next commit:
|
||||
* If the request references a GitHub team to be listed in the `OWNERS`
|
||||
file, update the `OWNERS_ALIASES` file to remove the steering-committee
|
||||
alias and add a new alias for the team with members populated as per the
|
||||
GitHub team. If the request does not reference a GitHub team, remove the
|
||||
`OWNERS_ALIASES` file.
|
||||
* Update the OWNERS file as per the request. If the repo is a
|
||||
[SIG Repository], add a labels entry for the SIG that the repo belongs to.
|
||||
* Update the `SECURITY_CONTACTS` file as per the request. Note that aliases
|
||||
cannot be used in this case so expand the GitHub team, if specified.
|
||||
* Create a new commit with the message *Update OWNERS, OWNERS_ALIASES and
|
||||
SECURITY_CONTACTS*.
|
||||
* Push the new commits directly to the master branch.
|
||||
* If the repo is a [SIG Repository], add a new topic of the form
|
||||
`k8s-sig-<sig-name-repo-belongs-to>` using the *Manage Topics* option.
|
||||
* Create a PR against [kubernetes/org] to add teams as per the [team guidance]
|
||||
for alloting repo admin and write access.
|
||||
* Once the above PR is merged and the postsubmit has run, the new GitHub teams
|
||||
will be created. In the *Collaborators and Teams* section in Settings,
|
||||
assign the new teams appropriate access to the repo.
|
||||
* Ask the author of the repo creation request to add the repo
|
||||
as a part of a subproject in [`sigs.yaml`](/sigs.yaml).
|
||||
|
||||
### Staging Repositories
|
||||
|
||||
If the repository is a staging repository, there are some deviations
|
||||
from the above procedure:
|
||||
|
||||
* The repository **must** have an initial empty commit. The contents of the
|
||||
repo will be populated from staging by the [publishing-bot].
|
||||
* Grant the [@kubernetes/stage-bots] team admin access to the repo.
|
||||
* Setup branch protection and enable access to the
|
||||
`stage-bots` team by adding the repo in
|
||||
[`prow/config.yaml`](https://git.k8s.io/test-infra/prow/config.yaml). See
|
||||
[kubernetes/test-infra#9292](https://github.com/kubernetes/test-infra/pull/9292)
|
||||
for an example.
|
||||
* Once the repo has been created, add the repo to
|
||||
[`hack/fetch-all-latest-and-push.sh`](https://git.k8s.io/publishing-bot/hack/fetch-all-latest-and-push.sh)
|
||||
in the [publishing-bot] repo.
|
||||
|
||||
<!-- TODO: Add suggestions for how to migrate existing repos -->
|
||||
|
||||
## Removing Repositories
|
||||
|
||||
As important as it is to add new repositories, it is equally important to prune
|
||||
|
|
@ -223,31 +161,6 @@ Associated repositories are much more loosely associated with the Kubernetes
|
|||
project and are generally not subject to removal, except under exceptional
|
||||
circumstances (e.g. a code of conduct violation).
|
||||
|
||||
### Procedure for removal
|
||||
|
||||
When a repository has been deemed eligible for removal, we take the following
|
||||
steps:
|
||||
|
||||
* Ownership of the repo is transferred to the [kubernetes-retired] GitHub
|
||||
organization
|
||||
* The repo description is edited to start with the phrase "[EOL]"
|
||||
* All open issues and PRs are closed
|
||||
* All external collaborators are removed
|
||||
* All webhooks, apps, integrations or services are removed
|
||||
* GitHub Pages are disabled
|
||||
* The repo is marked as archived using [GitHub's archive feature]
|
||||
* Remove all teams associated with the repo
|
||||
* Remove the repo from [sigs.yaml]
|
||||
* The removal is announced on the kubernetes-dev mailing list and community
|
||||
meeting
|
||||
|
||||
This maintains the complete record of issues, PRs and other contributions,
|
||||
leaves the repository read-only, and makes it clear that the repository should
|
||||
be considered retired and unmaintained.
|
||||
|
||||
In case a repository has only the initial commits adding template files
|
||||
and no additional activity, it can be completely deleted.
|
||||
|
||||
## FAQ
|
||||
|
||||
**My project is currently in kubernetes-incubator, what is going to happen to
|
||||
|
|
@ -306,14 +219,3 @@ owned by the authors of Kubernetes.
|
|||
|
||||
Note that you should _never_ modify or remove a third party's copyright notice if
|
||||
you are not authorized by them to do so.
|
||||
|
||||
[GitHub's archive feature]:
|
||||
https://help.github.com/articles/archiving-a-github-repository/
|
||||
[kubernetes-retired]: https://github.com/kubernetes-retired
|
||||
[kubernetes-template-project]: https://github.com/kubernetes/kubernetes-template-project
|
||||
[kubernetes/org]: https://github.com/kubernetes/org
|
||||
[team guidance]: /github-management/org-owners-guide.md#team-guidance
|
||||
[SIG Repository]: #sig-repositories
|
||||
[publishing-bot]: https://github.com/kubernetes/publishing-bot
|
||||
[@kubernetes/stage-bots]: https://github.com/orgs/kubernetes/teams/stage-bots
|
||||
[sigs.yaml]: /sigs.yaml
|
||||
|
|
|
|||
|
|
@ -41,7 +41,8 @@ managed by the Kubernetes project or use a different name.
|
|||
|
||||
Due to licensing and CLA issues, prior to transferring software into a
|
||||
Kubernetes managed organization there is some due diligence that needs to occur.
|
||||
Please contact the steering committee and CNCF prior to moving any code in.
|
||||
If needed, please contact the steering committee and CNCF prior to moving any
|
||||
code in.
|
||||
|
||||
It is easier to start new code in a Kubernetes organization than it is to
|
||||
transfer in existing code.
|
||||
|
|
@ -137,7 +138,97 @@ checking on all contributions. For more details on those please see the
|
|||
Project](https://github.com/kubernetes/kubernetes-template-project), and the
|
||||
[Repository Guidelines](kubernetes-repositories.md)
|
||||
|
||||
The process for creating and removing new repositories is detailed below.
|
||||
|
||||
### Creating Repositories
|
||||
|
||||
#### Non-staging repositories
|
||||
|
||||
For non-staging repositories, suggestions on how to create
|
||||
a new repository are described below.
|
||||
|
||||
* Ensure that the repo creation request has appropriate approvals
|
||||
as per the rules mentioned above.
|
||||
* Using the organization and repository name mentioned in the repo creation
|
||||
request, create a new repo with:
|
||||
* `Repository Template` as `kubernetes/kubernetes-template-project`
|
||||
* `Description` as mentioned in the repo creation request
|
||||
* Clone the newly created repo locally.
|
||||
* Make the following changes:
|
||||
* If the request references a team to be listed in the `OWNERS`
|
||||
file, update the `OWNERS_ALIASES` file to remove the steering-committee
|
||||
alias and add a new alias for the team with members populated as per the
|
||||
GitHub team. If the request does not reference a team, remove the
|
||||
`OWNERS_ALIASES` file.
|
||||
* Update the OWNERS file as per the request. If the repo is a
|
||||
[SIG Repository], add a labels entry for the SIG that the repo belongs to.
|
||||
* Update the `SECURITY_CONTACTS` file as per the request. Note that aliases
|
||||
cannot be used in this case so expand the team, if specified.
|
||||
* Create a new commit with the message *Update OWNERS, OWNERS_ALIASES and
|
||||
SECURITY_CONTACTS*.
|
||||
* Push the new commit directly to the master branch.
|
||||
* If the repo is a [SIG Repository], add a new topic of the form
|
||||
`k8s-sig-<sig-name-repo-belongs-to>` using the *Manage Topics* option.
|
||||
* Create a PR against [kubernetes/org] to add teams as per the [team guidance](#team-guidance)
|
||||
for alloting repo admin and write access.
|
||||
* Once the above PR is merged and the postsubmit has run, the new GitHub teams
|
||||
will be created. In the *Collaborators and Teams* section in Settings,
|
||||
assign the new teams appropriate access to the repo.
|
||||
* Ask the author of the repo creation request to add the repo
|
||||
as a part of a subproject in [`sigs.yaml`](/sigs.yaml).
|
||||
|
||||
#### Staging Repositories
|
||||
|
||||
If the repository is a staging repository, there are some deviations
|
||||
from the above procedure:
|
||||
|
||||
* The repository **must** have an initial empty commit. The contents of the
|
||||
repo will be populated from staging by the [publishing-bot].
|
||||
* Grant the [@kubernetes/stage-bots] team admin access to the repo.
|
||||
* Setup branch protection and enable access to the
|
||||
`stage-bots` team by adding the repo in
|
||||
[`prow/config.yaml`](https://git.k8s.io/test-infra/prow/config.yaml). See
|
||||
[kubernetes/test-infra#9292](https://github.com/kubernetes/test-infra/pull/9292)
|
||||
for an example.
|
||||
* Once the repo has been created, add the repo to
|
||||
[`hack/fetch-all-latest-and-push.sh`](https://git.k8s.io/publishing-bot/hack/fetch-all-latest-and-push.sh)
|
||||
in the [publishing-bot] repo.
|
||||
|
||||
<!-- TODO: Add suggestions for how to migrate existing repos -->
|
||||
|
||||
### Removing Repositories
|
||||
|
||||
When a repository has been deemed eligible for removal, we take the following
|
||||
steps:
|
||||
|
||||
* Ownership of the repo is transferred to the [kubernetes-retired] GitHub
|
||||
organization
|
||||
* The repo description is edited to start with the phrase "[EOL]"
|
||||
* All open issues and PRs are closed
|
||||
* All external collaborators are removed
|
||||
* All webhooks, apps, integrations or services are removed
|
||||
* GitHub Pages are disabled
|
||||
* Remove all teams associated with the repo
|
||||
* The repo is marked as archived using [GitHub's archive feature]
|
||||
* Remove the repo from [sigs.yaml]
|
||||
* The removal is announced on the kubernetes-dev mailing list and community
|
||||
meeting
|
||||
|
||||
This maintains the complete record of issues, PRs and other contributions,
|
||||
leaves the repository read-only, and makes it clear that the repository should
|
||||
be considered retired and unmaintained.
|
||||
|
||||
In case a repository has only the initial commits adding template files
|
||||
and no additional activity, it can be completely deleted.
|
||||
|
||||
[GitHub Administration Team]:
|
||||
/github-management/README.md#github-administration-team
|
||||
[GitHub's archive feature]:
|
||||
https://help.github.com/articles/archiving-a-github-repository/
|
||||
[@kubernetes/owners]: https://github.com/orgs/kubernetes/teams/owners
|
||||
[kubernetes/org]: https://github.com/kubernetes/org
|
||||
[publishing-bot]: https://github.com/kubernetes/publishing-bot
|
||||
[@kubernetes/stage-bots]: https://github.com/orgs/kubernetes/teams/stage-bots
|
||||
[kubernetes-retired]: https://github.com/kubernetes-retired
|
||||
[kubernetes-template-project]: https://github.com/kubernetes/kubernetes-template-project
|
||||
[SIG Repository]: /github-management/kubernetes-repositories.md##sig-repositories
|
||||
|
|
|
|||
Loading…
Reference in New Issue