|
1 |
| -# Kubernetes Template Project |
2 |
| - |
3 |
| -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: |
4 |
| - |
5 |
| -- a `README.md` outlining the project goals, sponsoring sig, and community contact information |
6 |
| -- an `OWNERS` with the project leads listed as approvers ([docs on `OWNERS` files][owners]) |
7 |
| -- a `CONTRIBUTING.md` outlining how to contribute to the project |
8 |
| -- an unmodified copy of `code-of-conduct.md` from this repo, which outlines community behavior and the consequences of breaking the code |
9 |
| -- a `LICENSE` which must be Apache 2.0 for code projects, or [Creative Commons 4.0] for documentation repositories, without any custom content |
10 |
| -- a `SECURITY_CONTACTS` with the contact points for the Product Security Team |
11 |
| - to reach out to for triaging and handling of incoming issues. They must agree to abide by the |
12 |
| - [Embargo Policy](https://github.com/kubernetes/sig-release/blob/master/security-release-process-documentation/security-release-process.md#embargo-policy) |
13 |
| - and will be removed and replaced if they violate that agreement. |
14 |
| - |
15 |
| -## Community, discussion, contribution, and support |
16 |
| - |
17 |
| -Learn how to engage with the Kubernetes community on the [community page](http://kubernetes.io/community/). |
18 |
| - |
19 |
| -You can reach the maintainers of this project at: |
20 |
| - |
21 |
| -- [Slack](http://slack.k8s.io/) |
22 |
| -- [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-dev) |
23 |
| - |
24 |
| -### Code of conduct |
25 |
| - |
26 |
| -Participation in the Kubernetes community is governed by the [Kubernetes Code of Conduct](code-of-conduct.md). |
27 |
| - |
28 |
| -[owners]: https://git.k8s.io/community/contributors/guide/owners.md |
29 |
| -[Creative Commons 4.0]: https://git.k8s.io/website/LICENSE |
| 1 | +# [csi-build-rules](https://github.com/kubernetes-csi/csi-build-rules) |
| 2 | + |
| 3 | +These build and test rules can be shared between different Go projects |
| 4 | +without modifications. Customization for the different projects happen |
| 5 | +in the top-level Makefile. |
| 6 | + |
| 7 | +The rules include support for building and pushing Docker images, with |
| 8 | +the following features: |
| 9 | + - one or more command and image per project |
| 10 | + - push canary and/or tagged release images |
| 11 | + - automatically derive the image tag(s) from repo tags |
| 12 | + - the source code revision is stored in a "revision" image label |
| 13 | + - never overwrites an existing release image |
| 14 | + |
| 15 | +Usage |
| 16 | +----- |
| 17 | + |
| 18 | +The expected repository layout is: |
| 19 | + - `cmd/*/*.go` - source code for each command |
| 20 | + - `cmd/*/Dockerfile` - docker file for each command or |
| 21 | + Dockerfile in the root when only building a single command |
| 22 | + - `Makefile` - includes `build-rules/build.make` and sets |
| 23 | + configuration variables |
| 24 | + - `.travis.yml` - a symlink to `build-rules/.travis.yml` |
| 25 | + |
| 26 | +To create a release, tag a certain revision with a name that |
| 27 | +starts with `v`, for example `v1.0.0`, then `make push` |
| 28 | +while that commit is checked out. |
| 29 | + |
| 30 | +It does not matter on which branch that revision exists, i.e. it is |
| 31 | +possible to create releases directly from master. A release branch can |
| 32 | +still be created for maintenance releases later if needed. |
| 33 | + |
| 34 | +Release branches are expected to be named `release-x.y` for releases |
| 35 | +`x.y.z`. Building from such a branch creates `x.y-canary` |
| 36 | +images. Building from master creates the main `canary` image. |
| 37 | + |
| 38 | +Sharing and updating |
| 39 | +-------------------- |
| 40 | + |
| 41 | +[`git subtree`](https://github.com/git/git/blob/master/contrib/subtree/git-subtree.txt) |
| 42 | +is the recommended way of maintaining a copy of the rules inside the |
| 43 | +`build-rules` directory of a project. This way, it is possible to make |
| 44 | +changes also locally, test them and then push them back to the shared |
| 45 | +repository at a later time. |
| 46 | + |
| 47 | +Cheat sheet: |
| 48 | + |
| 49 | +- `git subtree pull --prefix=build-rules https://github.com/kubernetes-csi/csi-build-rules.git master` - update local copy to latest upstream |
| 50 | +- 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 |
0 commit comments