-
Notifications
You must be signed in to change notification settings - Fork 260
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 #5
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 ...
build.make: fix pushing of "canary" image from master branch
test enhancements
This imports the shared csi-release-tools and uses it for Travis CI and building. The binary and image name are "nfsplugin", as before.
Travis CI still needs to be activated for this repo. This can only be done by someone in the kubernetes-csi admin group. Once this PR is merged, we should get a "canary" image for the master branch build that gets triggered by merging. |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: msau42, 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 |
I enabled travis. We'll see on the next pull if it works. I tried to manually trigger a build, but it was still skipping the image pushing part for some reason |
PR builds don't push images. We don't want them to overwrite any of the other images, and generating one image per PR would probably be too much garbage. https://travis-ci.org/kubernetes-csi/csi-driver-nfs/builds/497214712 shows that a master branch build tried to push quay.io/k8scsi/nfsplugin:canary, but that failed:
Do we want TravisCI to report job success despite the failure to push the image? This has always been this way, because pushing is done in an If we wanted pushing to be part of the job, it would have to be part of the build script. |
Sorry I don't mean PR builds should push images, I meant that the job I triggered off of the master branch didn't push. Let me investigate the authorization error. |
Michelle Au <[email protected]> writes:
Sorry I don't mean PR builds should push images
So we agree :-) I just mentioned it because it could have been one
reason why nothing was pushed.
|
# This is the 1st commit message: setup travis running e2e tests on the nfs driver # The commit message kubernetes-csi#2 will be skipped: # remove release-tools # The commit message kubernetes-csi#3 will be skipped: # test travis with no makefile in config # The commit message kubernetes-csi#4 will be skipped: # change path # The commit message kubernetes-csi#5 will be skipped: # adding e2e test to travis ci # The commit message kubernetes-csi#6 will be skipped: # add travis build status on README # The commit message kubernetes-csi#7 will be skipped: # fix travis script # The commit message kubernetes-csi#8 will be skipped: # use local-up-cluster instead of dind for travis CI
release tools
This imports the shared csi-release-tools and uses it for Travis CI
and building. The binary and image name are "nfsplugin", as before.
/assign @msau42