fix: make compatibility versions test use dynamic n-1 branch for test (from hardcoded release-1.31)

aaron-prindle commented 21 hours ago

Fixes #33573

This PR modifies experiment/compatibility-versions/e2e-k8s-compatibility-versions.sh to fetch the latest release-X.Y branch from https://github.com/kubernetes/kubernetes.git and use that as the n-1 version for compatibility versions testing. This way this test is dynamic and updates the n-1 version as new releases are made - updating automatically over time vs the current hardcoded release-1.31 value currently present in the test.

k8s-ci-robot commented 21 hours ago

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: aaron-prindle Once this PR has been reviewed and has the lgtm label, please assign wojtek-t for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files: - **[config/OWNERS](https://github.com/kubernetes/test-infra/blob/master/config/OWNERS)** - ~~[experiment/compatibility-versions/OWNERS](https://github.com/kubernetes/test-infra/blob/master/experiment/compatibility-versions/OWNERS)~~ [aaron-prindle] Approvers can indicate their approval by writing `/approve` in a comment Approvers can cancel approval by writing `/approve cancel` in a comment

aaron-prindle commented 7 hours ago

/cc @BenTheElder

BenTheElder commented 7 hours ago

TLDR I think:

let's determine which release we're on currently by using hack/print-workspace-status.sh (so single source of truth about kube versioning from the main repo), that way this script "just works" for 1.32, 1.33, 1.34, ... (instead of floating with the current latest)
then we can compute the N-1 or N-2 release minor version (maybe we should make the constant minor back-compat offset a variable with a default of 1 or 2?)
we can then do kind build node image v1.N-1.(latest) (TODO: we can get latest from git tag | grep 'v1.N-1.' ?)
create kind cluster from this image, ensure --compat-version is set to N-1
then we can build and patch in api-server from the current branch
run tests from N-1 ? (we can also download these the same as kind downloading the component release binaries)

aaron-prindle commented 3 hours ago

let's determine which release we're on currently by using hack/print-workspace-status.sh (so single source of truth about kube versioning from the main repo), that way this script "just works" for 1.32, 1.33, 1.34, ... (instead of floating with the current latest) Ah I didn't know about hack/print-workspace-status.sh, thanks! I've updated the logic here to use that script vs looking at the git remote information.

then we can compute the N-1 or N-2 release minor version (maybe we should make the constant minor back-compat offset a variable with a default of 1 or 2?) Currently I've updated this PR to compute only the N-1 release minor version as v1.31-v1.32 are the only versions support for Compatibility Versions currently

Currently the PR is focused on fixing #33573. I've created #33849 to track the issue with the kubelet version being incorrect. I will address the below points in a separate PR to fix #33849 if that is ok. Can also do them both in the PR, currently my plan is to do them in 2 PRs though.

we can then do kind build node image v1.N-1.(latest) (TODO: we can get latest from git tag | grep 'v1.N-1.' ?)

create kind cluster from this image, ensure --compat-version is set to N-1

then we can build and patch in api-server from the current branch

run tests from N-1 ? (we can also download these the same as kind downloading the component release binaries)

kubernetes / test-infra

fix: make compatibility versions test use dynamic n-1 branch for test (from hardcoded release-1.31) #33837