-
Notifications
You must be signed in to change notification settings - Fork 63
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 #6
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. Everything is set up to build the "iscsiplugin" binary and image, but as there is no Dockerfile yet, image creation and pushing is not active.
Travis CI still needs to be activated for this repo. This can only be done by someone in the kubernetes-csi admin group. |
/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 |
Pull request builds don't push images. If they did, which tag should they use? |
Wait, this repo is the one which doesn't have a Dockerfile, therefore image building is not enabled in the Makefile. |
This imports the shared csi-release-tools and uses it for Travis CI
and building. The binary and image name are expected to be "iscsiplugin",
but a Dockerfile still needs to be added by someone who knows what needs
to be in it.
/assign @msau42