-
Notifications
You must be signed in to change notification settings - Fork 150
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
Update release-tools to support building on Mac OS X #267
Update release-tools to support building on Mac OS X #267
Conversation
Developers should not be forced to build for all platforms by default. We also don't want to copy-and-paste the go invocation for each new platform. To address both, the target platform(s) are now configurable via BUILD_PLATFORMS and additional platforms are only enabled in the Prow CI. For now this serves as a test that the source actually compiles for multiple platforms. Building images for different target platforms is a different problem.
build for multiple platforms only in CI, add s390x
Signed-off-by: Grant Griffiths <[email protected]>
…pdate Update snapshotter to version 2.0.1
update release tools instructions
Signed-off-by: Grant Griffiths <[email protected]>
…ter_rbac_version_set Fix csi-snapshotter RBAC yaml version
Update patch release notes generation command
Hi @timoreimann. Thanks for your PR. I'm waiting for a kubernetes-csi member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
/ok-to-test |
All tests seem to pass, and yet the build is red. I can see
being logged. I wonder if the fact that I modified the release tooling is the problem? This comment hints at that. If that's true, how'd I go about making the necessary change? |
The |
This adds support for building csi-test binaries for the local platform (as opposed to be being hard-wired to Linux previously). Merge commit '9084fecb84ddb47af8360d9ebe4f48a6b7a65c1d' into support-building-on-mac-os
0a37399
to
d73d0cd
Compare
@pohly turned out kubernetes-csi/csi-release-tools already had support for building natively, so all it takes for us is to bump csi-test's subtree reference to the latest master. I updated the PR accordingly, please take a look again whenever you have a moment. |
Just to be clear because Github makes it look like I pushed more changes than I actually did: for this PR I invoked
and pushed a single commit. I think Github's support for displaying subtree-based changes is still behind its capabilities to do the same in submodules cases. |
Would be nice if I had remembered that I already changed that, right? 😝 ETOOMUCHGOINGON
This has confused others in the past, too. The advantage of subtree is that it is easy to do a test PR in a component using csi-release-tools and then submit that same commit against csi-release-tools itself. Might be worthwhile to reconsider the tool choice, though. |
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.
/approve
/lgtm
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: pohly, timoreimann 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 |
What type of PR is this?
What this PR does / why we need it:
Building / running on tests on Mac OS X does not work. This change updates the release-tools to the kubernetes-csi/csi-release-tools@9084fec which already has support for native building/compiling.
Does this PR introduce a user-facing change?: