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
Go workspaces for k/k and k/staging/* #123529
Conversation
Needed because defaulter-gen tests end up depending on apimachinery.
Because of how the previous 100+ commits were done, so changes snuck thru that properly belong in earlier commits but it's not really possible to do that without a lot of effort. We agreed it was OK to "spackle" these cracks with a final commit.
Reverted the BUILDNAME stuff. Removed FIXME. I think it's done. All comments resolved. CI passed last time, so unless I horked something it should pass now. @liggitt if you are happy me, slap me with some LGTM. But please actually BE happy. |
/retest |
/approve will wait for @liggitt to remove hold |
LGTM label has been added. Git tree hash: bad7702dd466d0e53c4b69d82a6e0d3536e192c4
|
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.
/lgtm
/approve
One non-blocking nit, unhold at will. May the rebase conflict odds be ever in your favor.
_KUBE_OUTPUT_SUBPATH="${KUBE_OUTPUT_SUBPATH:-_output/local}" | ||
export KUBE_OUTPUT="${KUBE_ROOT}/${_KUBE_OUTPUT_SUBPATH}" |
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.
non-blocking nit, could be a follow-up cleanup, but this would get you one less ambient bash var:
_KUBE_OUTPUT_SUBPATH="${KUBE_OUTPUT_SUBPATH:-_output/local}" | |
export KUBE_OUTPUT="${KUBE_ROOT}/${_KUBE_OUTPUT_SUBPATH}" | |
export KUBE_OUTPUT="${KUBE_ROOT}/${KUBE_OUTPUT_SUBPATH:-_output/local}" |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dims, liggitt, thockin 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 |
/unhold Fire in the hole! |
Live picture of @thockin !! |
What's the over/under on time to first explosion? |
@thockin - as soon as |
/honk |
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. |
KEP: kubernetes/enhancements#4402
This is a new PR based on #122624, to clear the lengthy history.
What is it?
The main Kubernetes git repo (github.com/kubernetes/kubernetes, colloquially called "k/k") is the embodiment of evolution. When it was created, the only way to build Go applications was GOPATH. Over time we built tooling which understood GOPATH, and it leaked into many parts of our build, test, and release systems. Then Go added modules, in part because GOPATH was unpleasant and had a tendency to leak into tools. We adopted modules, but we also added the idea of "staging" repositories - a way to eat our cake and have, too. We get the benefits of a monorepo (atomic commits, fast iteration across repos) and then publish those to standalone repos for downstream consumption. To make this work with modules, we abused GOPATH even harder and wrote even more tools.
The Go project saw what we (and others) were doing and did not like it. So they created workspaces. They basically created a solution that is purpose-built for us.
Let's use it.
On reviewing: Review each commit individually. This PR was crafted in lock-step with a series of gengo commits, but since those are merged and gengo is in a different repo, we can't really see those any more. This means that a lot of things don't work at each commit in this PR. This is the only way this could be a sane PR to review though (if you call this sane).
I fully expect that once this merges we will find a long-tail of out-of-tree impacts (tests which need to use go 1.22, etc).
One major aspect of this is code-generation. It's FAR simpler now, but how does it perform? After factoring out build time (by doing a full build first) we can see it has little impact:
before:
after:
/kind bug
/kind cleanup
/kind feature
/kind api-change