Allow staging via krel for kubetest#19488
Allow staging via krel for kubetest#19488saschagrunert wants to merge 1 commit intokubernetes:masterfrom
Conversation
|
cc @kubernetes/release-engineering |
xmudrii
left a comment
There was a problem hiding this comment.
Left two nits, but otherwise looks okay to me.
5325020 to
3c0aa6f
Compare
3ce4a44 to
0c01494
Compare
|
Green tests 💚 |
0c01494 to
d8782db
Compare
|
Rebased on top of the latest master branch. |
a2315ff to
5068e8b
Compare
5068e8b to
1f3085f
Compare
|
/retest |
Hm, it looks like the project does not build any more correctly with the dependency change… 🤔 |
|
needs rebase |
fc63c52 to
725a1e1
Compare
725a1e1 to
bd6e43f
Compare
bd6e43f to
052daf3
Compare
This adds a new `--use-krel` flag to kubetest to indicate that we want to stage the sources directly via the API provided by k/release rather than the deprecated push-build.sh script (lives in k/release, too). The idea is to add another job later on for testing this flag on a non critical Kubernetes build+push job (should live in sig-release). Signed-off-by: Sascha Grunert <sgrunert@suse.com> Signed-off-by: Sascha Grunert <mail@saschagrunert.de>
052daf3 to
2894d43
Compare
|
|
||
| http://www.apache.org/licenses/LICENSE-2.0 | ||
|
|
||
| http://www.apache.org/licenses/LICENSE-2.0 |
There was a problem hiding this comment.
Looks like this file is causing the boilerplate test to fail, but I did not change it in this PR. 🤷
Done, please take another look :) |
|
didn't we land this in kubetest2? I'm also concerned about dependency cycles, like #20422 |
Yes, the main intention of this change is to be able to completely remove the |
|
Can we close or update or lgtm or whatever this PR? Looks like it also needs a rebase now |
|
@saschagrunert: PR needs rebase. DetailsInstructions 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. |
|
+1 hesistant to make changes to kubetest. We've landed this in kubetest2 successfully and I'm working on a migration plan for kubetest deprecation. I'm inclined to have it solved that way. |
to what end though? is this script actually being actively touched today? if so: why? As a general rule we avoid substantially changing CI for existing kubernetes release branches, so we'd probably want to wait N releases to no longer have any jobs using this.
I'm not sure we should be converting old release branches, regardless of if it's swapping out push-build.sh, or kubetest ... |
BenTheElder
left a comment
There was a problem hiding this comment.
I'm not sure if it's just because the PR is out of date, but this seems prettty heavy on the dependencies for something that should just need to talk to GCS and read some files from disk ...
| name = "com_github_bazelbuild_rules_go", | ||
| build_file_generation = "on", | ||
| build_file_proto_mode = "disable", | ||
| importpath = "github.com/bazelbuild/rules_go", |
There was a problem hiding this comment.
why are we now importing rules_go as a go library? 🤔
| name = "com_github_cilium_ebpf", | ||
| build_file_generation = "on", | ||
| build_file_proto_mode = "disable", | ||
| importpath = "github.com/cilium/ebpf", |
|
As it looks like that the majority does not want this PR to get merged :) |
|
@saschagrunert: Closed this PR. DetailsIn 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. |
We changed a bunch of dependencies in k/release so we can give this a try again
This adds a new
--use-krelflag to kubetest to indicate that we want to stage the sources directly via the API provided by k/release rather than the deprecated push-build.sh script (lives in k/release, too).The idea is to add another job later on for testing this flag on a non critical Kubernetes build+push job (should live in sig-release).