alexlebens/external-snapshotter
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Merge pull request #1 from pohly/master

Browse Source 
initial content
This commit is contained in:
Kubernetes Prow Robot
2019-01-21 12:51:32 -08:00
committed by GitHub
parent d23a16cb74 c876547b7f
commit b32dd0106a
3 changed files with 109 additions and 1218 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
README.md
View File

@@ -1,4 +1,4 @@
# [csi-build-rules](https://github.com/kubernetes-csi/csi-build-rules) # [csi-release-tools](https://github.com/kubernetes-csi/csi-release-tools)
These build and test rules can be shared between different Go projects These build and test rules can be shared between different Go projects
without modifications. Customization for the different projects happen without modifications. Customization for the different projects happen
@@ -19,9 +19,9 @@ The expected repository layout is:
- `cmd/*/*.go` - source code for each command - `cmd/*/*.go` - source code for each command
- `cmd/*/Dockerfile` - docker file for each command or - `cmd/*/Dockerfile` - docker file for each command or
Dockerfile in the root when only building a single command Dockerfile in the root when only building a single command
- `Makefile` - includes `build-rules/build.make` and sets - `Makefile` - includes `release-tools/build.make` and sets
configuration variables configuration variables
- `.travis.yml` - a symlink to `build-rules/.travis.yml` - `.travis.yml` - a symlink to `release-tools/.travis.yml`
To create a release, tag a certain revision with a name that To create a release, tag a certain revision with a name that
starts with `v`, for example `v1.0.0`, then `make push` starts with `v`, for example `v1.0.0`, then `make push`
@@ -40,11 +40,12 @@ Sharing and updating
[`git subtree`](https://github.com/git/git/blob/master/contrib/subtree/git-subtree.txt) [`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 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 `release-tools` directory of a project. This way, it is possible to make
changes also locally, test them and then push them back to the shared changes also locally, test them and then push them back to the shared
repository at a later time. repository at a later time.
Cheat sheet: Cheat sheet:
- `git subtree pull --prefix=build-rules https://github.com/kubernetes-csi/csi-build-rules.git master` - update local copy to latest upstream - `git subtree add --prefix=release-tools https://github.com/pohly/csi-release-tools.git master` - add release tools to a repo which does not have them yet (only once)
- 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 - `git subtree pull --prefix=release-tools https://github.com/kubernetes-csi/csi-release-tools.git master` - update local copy to latest upstream (whenever upstream changes)
- edit, `git commit`, `git subtree push --prefix=release-tools git@github.com:<user>/csi-release-tools.git <my-new-or-existing-branch>` - push to a new branch before submitting a PR

4
RELEASE.md
View File

@@ -1,3 +1,5 @@
# Release Process # Release Process
TODO: describe the release process for this project No tagged releases are planned at this point. The intention is to keep
the master branch in a state such that it can be used for all
supported branches in downstream repos which use these files.

1310
build.make
View File

File diff suppressed because it is too large Load Diff