Add files from github.com/pohly/csi-build-rules
This commit is contained in:
61
README.md
61
README.md
@@ -1,29 +1,50 @@
|
|||||||
# Kubernetes Template Project
|
# [csi-build-rules](https://github.com/kubernetes-csi/csi-build-rules)
|
||||||
|
|
||||||
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:
|
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.
|
||||||
|
|
||||||
- a `README.md` outlining the project goals, sponsoring sig, and community contact information
|
The rules include support for building and pushing Docker images, with
|
||||||
- an `OWNERS` with the project leads listed as approvers ([docs on `OWNERS` files][owners])
|
the following features:
|
||||||
- a `CONTRIBUTING.md` outlining how to contribute to the project
|
- one or more command and image per project
|
||||||
- an unmodified copy of `code-of-conduct.md` from this repo, which outlines community behavior and the consequences of breaking the code
|
- push canary and/or tagged release images
|
||||||
- a `LICENSE` which must be Apache 2.0 for code projects, or [Creative Commons 4.0] for documentation repositories, without any custom content
|
- automatically derive the image tag(s) from repo tags
|
||||||
- a `SECURITY_CONTACTS` with the contact points for the Product Security Team
|
- the source code revision is stored in a "revision" image label
|
||||||
to reach out to for triaging and handling of incoming issues. They must agree to abide by the
|
- never overwrites an existing release image
|
||||||
[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
|
Usage
|
||||||
|
-----
|
||||||
|
|
||||||
Learn how to engage with the Kubernetes community on the [community page](http://kubernetes.io/community/).
|
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`
|
||||||
|
|
||||||
You can reach the maintainers of this project at:
|
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.
|
||||||
|
|
||||||
- [Slack](http://slack.k8s.io/)
|
It does not matter on which branch that revision exists, i.e. it is
|
||||||
- [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-dev)
|
possible to create releases directly from master. A release branch can
|
||||||
|
still be created for maintenance releases later if needed.
|
||||||
|
|
||||||
### Code of conduct
|
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.
|
||||||
|
|
||||||
Participation in the Kubernetes community is governed by the [Kubernetes Code of Conduct](code-of-conduct.md).
|
Sharing and updating
|
||||||
|
--------------------
|
||||||
|
|
||||||
[owners]: https://git.k8s.io/community/contributors/guide/owners.md
|
[`git subtree`](https://github.com/git/git/blob/master/contrib/subtree/git-subtree.txt)
|
||||||
[Creative Commons 4.0]: https://git.k8s.io/website/LICENSE
|
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 git@github.com:<user>/csi-build-rules.git <my-new-or-existing-branch>` - push to a new branch before submitting a PR
|
||||||
|
1211
build.make
Normal file
1211
build.make
Normal file
File diff suppressed because it is too large
Load Diff
14
travis.yml
Normal file
14
travis.yml
Normal file
@@ -0,0 +1,14 @@
|
|||||||
|
language: go
|
||||||
|
sudo: required
|
||||||
|
services:
|
||||||
|
- docker
|
||||||
|
matrix:
|
||||||
|
include:
|
||||||
|
- go: 1.11.1
|
||||||
|
script:
|
||||||
|
- make all test
|
||||||
|
after_success:
|
||||||
|
- if [ "${TRAVIS_PULL_REQUEST}" == "false" ]; then
|
||||||
|
docker login -u "${DOCKER_USERNAME}" -p "${DOCKER_PASSWORD}" quay.io;
|
||||||
|
make push;
|
||||||
|
fi
|
Reference in New Issue
Block a user