-
Notifications
You must be signed in to change notification settings - Fork 151
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
release tools #156
release tools #156
Conversation
The repo was created with an HTML version of the build.make file from https://github.com/pohly/csi-build-rules/. Here's the raw file.
It's worth calling out explicitly that only the master branch is maintained.
The actual repository was not named like the prototype repo.
initial content
Copy-and-paste error from the time when the kubernetes-csi/csi-release-tools repo didn't have the code...
README.md: fix repo URL for initial setup
The goal is to enforce that changes get merged upstream first and only get into the local repo via a normal "git subtree merge".
"make test" used to abort after the first test failure. That was partly intentional: if the simple tests already fail (for example, because of a syntax error), then there is no point in continuing to test. However, it also makes it harder to find all errors in a CI system when the errors are unrelated (first error shows up, gets fixed, next error shows up, etc.). Now "make test" still aborts early, but "make -k test" is used in the CI and will run all individual tests because they are split up into different targets.
We don't want to allow local modifications in the subtree. Everything should go to the csi-release-tools repo first.
check subtree for changes
This may or may not work, depending on which packages have tests and whether they contain glog.
Individual repos may have to filter out certain packages from testing. For example, in csi-test the cmd/csi-sanity directory contains a special test that depends on additional parameters that set the CSI driver to test against.
After merging into external-attacher, the next Travis CI run did not push the "canary" image because the check for "canary" only covered the case where "-canary" is used as suffix (https://travis-ci.org/kubernetes-csi/external-attacher/builds/484095261).
The introduction for each individual test looked like an actual command: test-subtree ./release-tools/verify-subtree.sh release-tools Directory 'release-tools' contains non-upstream changes: ... It's better to make it look like a shell comment and increase its visibility with a longer prefix: ### test-subtree: ./release-tools/verify-subtree.sh release-tools ...
/hold |
build.make: fix pushing of "canary" image from master branch
test enhancements
/hold cancel |
/lgtm |
@bswartz: changing LGTM is restricted to assignees, and only kubernetes-csi/csi-test repo collaborators may be assigned issues. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
This switches building over to the shared csi-sanity-tools, which makes it simpler to keep building in the different repos in sync. For example, this now bumps the Go version to 1.11.1. For this to work, some files must be moved around to match the expected layout.
Rebased because of the merge conflict with 4df3ede |
The new check actually works as intended:
I need to fix the code before enforcing this check. |
PR #166 has to be merged first to get a clean test result. |
|
||
Cheat sheet: | ||
|
||
- `git subtree add --prefix=release-tools https://github.com/kubernetes-csi/csi-release-tools.git master` - add release tools to a repo which does not have them yet (only once) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have to be honest about this, I feel this is really overkill for this project and is quite different from a normal git release process.
I'm concerned that I am going to mess something up (that's my biggest concern)
@@ -0,0 +1,5 @@ | |||
# Release Process | |||
|
|||
No tagged releases are planned at this point. The intention is to keep |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this have the explanation on how to use this, or is it the README.md that we should follow?
docker tag $*:latest $(IMAGE_NAME):$$tag; \ | ||
docker push $(IMAGE_NAME):$$tag; \ | ||
}; \ | ||
for tag in $(IMAGE_TAGS); do \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To me this is almost magic. I am concerned with the maintenance of these tools and scripts. I feel only the author can maintain it and that is concerning.
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: lpabon, pohly The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
release tools
This syncs the build rules with the other kubernetes-csi repos.