-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Move tools into separate hack
go module
#10308
Conversation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: rifelpet 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 |
hack
go modulehack
go module
I'll need to figure out how to reference the new go-bindata location within this bazel rule Lines 23 to 33 in e789c24
|
hack
go modulehack
go module
this is ready for review. as mentioned in the original comment I had to back out some of the moves, we can address them in followup PRs. |
This looks good! Works as intended locally. /lgtm |
/retest Review the full test history for this PR. Silence the bot with an |
This follows a pattern used in other projects moving imports used only in development tools into a separate go module. The new module does not use vendoring. all scripts and make targets that use the tools will now build them into
_output/bin/
.I updated the goimports python scripts to rely less on GOPATH but the
goimports
tool itself still relies on it.EDIT: i opted to keep go-bindata in the root module because bazel depends on it and I haven't yet figured out how we could best handle that without vendoring go-bindata somewhere:
kops/upup/models/BUILD.bazel
Lines 23 to 30 in c621819
also update-machinery.sh still relies on GOPATH, we can update this in a followup PR