public_git
/
kubernetes-sigs_nfs-subdir-external-provisioner
mirror of https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

README.md: update repo name, add initial setup step 

The actual repository was not named like the prototype repo.
This commit is contained in:
Patrick Ohly 2019-01-21 10:26:11 +01:00
parent 51e16be615
commit c876547b7f
1 changed files with 7 additions and 6 deletions
Show Stats 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