Add files from github.com/pohly/csi-build-rules
This commit is contained in:
		
							parent
							
								
									0535c0d4f1
								
							
						
					
					
						commit
						b41cac350d
					
				
							
								
								
									
										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 | ||||
| - 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. | ||||
| 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 | ||||
| 
 | ||||
| ## 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/) | ||||
| - [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-dev) | ||||
| 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. | ||||
| 
 | ||||
| ### 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 | ||||
| [Creative Commons 4.0]: https://git.k8s.io/website/LICENSE | ||||
| [`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 git@github.com:<user>/csi-build-rules.git <my-new-or-existing-branch>` - push to a new branch before submitting a PR | ||||
|  |  | |||
										
											
												File diff suppressed because it is too large
												Load Diff
											
										
									
								
							|  | @ -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 | ||||
		Loading…
	
		Reference in New Issue