forked from kubernetes-csi/livenessprobe
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Add files from github.com/pohly/csi-build-rules
- Loading branch information
Showing
3 changed files
with
1,275 additions
and
29 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,29 +1,50 @@ | ||
| # Kubernetes Template Project | ||
|
|
||
| The Kubernetes Template Project is a template for starting new projects in the GitHub organizations owned by Kubernetes. All Kubernetes projects, at minimum, must have the following files: | ||
|
|
||
| - a `README.md` outlining the project goals, sponsoring sig, and community contact information | ||
| - an `OWNERS` with the project leads listed as approvers ([docs on `OWNERS` files][owners]) | ||
| - a `CONTRIBUTING.md` outlining how to contribute to the project | ||
| - an unmodified copy of `code-of-conduct.md` from this repo, which outlines community behavior and the consequences of breaking the code | ||
| - a `LICENSE` which must be Apache 2.0 for code projects, or [Creative Commons 4.0] for documentation repositories, without any custom content | ||
| - a `SECURITY_CONTACTS` with the contact points for the Product Security Team | ||
| to reach out to for triaging and handling of incoming issues. They must agree to abide by the | ||
| [Embargo Policy](https://github.com/kubernetes/sig-release/blob/master/security-release-process-documentation/security-release-process.md#embargo-policy) | ||
| and will be removed and replaced if they violate that agreement. | ||
|
|
||
| ## Community, discussion, contribution, and support | ||
|
|
||
| Learn how to engage with the Kubernetes community on the [community page](http://kubernetes.io/community/). | ||
|
|
||
| You can reach the maintainers of this project at: | ||
|
|
||
| - [Slack](http://slack.k8s.io/) | ||
| - [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-dev) | ||
|
|
||
| ### Code of conduct | ||
|
|
||
| Participation in the Kubernetes community is governed by the [Kubernetes Code of Conduct](code-of-conduct.md). | ||
|
|
||
| [owners]: https://git.k8s.io/community/contributors/guide/owners.md | ||
| [Creative Commons 4.0]: https://git.k8s.io/website/LICENSE | ||
| # [csi-build-rules](https://github.com/kubernetes-csi/csi-build-rules) | ||
|
|
||
| These build and test rules can be shared between different Go projects | ||
| without modifications. Customization for the different projects happen | ||
| in the top-level Makefile. | ||
|
|
||
| The rules include support for building and pushing Docker images, with | ||
| the following features: | ||
| - one or more command and image per project | ||
| - push canary and/or tagged release images | ||
| - automatically derive the image tag(s) from repo tags | ||
| - the source code revision is stored in a "revision" image label | ||
| - never overwrites an existing release image | ||
|
|
||
| Usage | ||
| ----- | ||
|
|
||
| The expected repository layout is: | ||
| - `cmd/*/*.go` - source code for each command | ||
| - `cmd/*/Dockerfile` - docker file for each command or | ||
| Dockerfile in the root when only building a single command | ||
| - `Makefile` - includes `build-rules/build.make` and sets | ||
| configuration variables | ||
| - `.travis.yml` - a symlink to `build-rules/.travis.yml` | ||
|
|
||
| To create a release, tag a certain revision with a name that | ||
| starts with `v`, for example `v1.0.0`, then `make push` | ||
| while that commit is checked out. | ||
|
|
||
| It does not matter on which branch that revision exists, i.e. it is | ||
| possible to create releases directly from master. A release branch can | ||
| still be created for maintenance releases later if needed. | ||
|
|
||
| Release branches are expected to be named `release-x.y` for releases | ||
| `x.y.z`. Building from such a branch creates `x.y-canary` | ||
| images. Building from master creates the main `canary` image. | ||
|
|
||
| Sharing and updating | ||
| -------------------- | ||
|
|
||
| [`git subtree`](https://github.com/git/git/blob/master/contrib/subtree/git-subtree.txt) | ||
| is the recommended way of maintaining a copy of the rules inside the | ||
| `build-rules` directory of a project. This way, it is possible to make | ||
| changes also locally, test them and then push them back to the shared | ||
| repository at a later time. | ||
|
|
||
| Cheat sheet: | ||
|
|
||
| - `git subtree pull --prefix=build-rules https://github.com/kubernetes-csi/csi-build-rules.git master` - update local copy to latest upstream | ||
| - edit, `git commit`, `git subtree push --prefix=build-rules [email protected]:<user>/csi-build-rules.git <my-new-or-existing-branch>` - push to a new branch before submitting a PR |
Oops, something went wrong.