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 | 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 | ||||||
|  |  | ||||||
										
											
												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