Pickup kind commit that fixes node image building#14948
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: msau42 The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/assign @davidz627 |
| args: | ||
| - ./.prow.sh | ||
| env: | ||
| # TODO: change to v0.6.0 |
There was a problem hiding this comment.
why is there a TODO on all of these - if necessary please add exit criterea or tracking bug for context
There was a problem hiding this comment.
Using a specific commit of kind is a workaround until kind releases a new version. Updated with bug reference
|
/lgtm |
|
@msau42: Updated the
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. |
|
As a stop-gap measure this is okay, but I think it's cleaner to let individual projects pick the version of kind that works for them and what they need kind for. |
I actually prefer the model where all versions are defined in configs and the prow.sh script itself has as few versions encoded in it as possible. It makes it a lot simpler to apply changes consistently across all repos. I don't see a strong use case for having different repos use different versions and it has not come up as a need for us yet. If different repos really want different configs, then they can specify that here. |
|
Michelle Au <notifications@github.com> writes:
I actually prefer the model where all versions are defined in configs
and the prow.sh script itself has as few versions encoded in it as
possible. It makes it a lot simpler to apply changes consistently
across all repos.
There are two sides of the coin here. When moving configuration into the
job definition, then it becomes harder to keep the configuration
consistent with the source code.
If you ever get into a situation where source code and configuration
need to be changed in lock-step, then merging is blocked: the source
code might fail with the current test configuration and thus cannot be
merged. The test configuration in test-infra cannot be merged either
because then other PRs in the project fail.
It also becomes harder to do maintenance releases. Old branches of a
project may need a different test configuration than master, so you
would have to start defining different jobs for different branches.
|
Tested new kind version in kubernetes-csi/csi-driver-host-path#106
Fixes: kubernetes-csi/csi-release-tools#38