Skip to content
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.

Sign up for GitHub

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

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

Merged
merged 1 commit into from
Dec 4, 2024
Merged

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

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 0 additions & 2 deletions config/jobs/kubernetes/sig-testing/compatibility-versions-e2e.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -35,8 +35,6 @@ periodics:
- -c
- curl -sSL https://kind.sigs.k8s.io/dl/latest/linux-amd64.tgz | tar xvfz - -C "${PATH%%:*}/" && ./../test-infra/experiment/compatibility-versions/e2e-k8s-compatibility-versions.sh
env:
- name: EMULATED_VERSION
value: "1.31" # TODO(aaron-prindle) FIXME - hardcoded for now
- name: SKIP
value: Alpha|Disruptive|Slow|Flaky|IPv6|LoadBalancer|PodSecurityPolicy|nfs
- name: PARALLEL
Expand Down
31 changes: 15 additions & 16 deletions experiment/compatibility-versions/e2e-k8s-compatibility-versions.sh
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -223,9 +223,6 @@ EOF

# run e2es with ginkgo-e2e.sh
run_tests() {
# Change to the cloned Kubernetes repository
pushd ../kubernetes

# IPv6 clusters need some CoreDNS changes in order to work in k8s CI:
# 1. k8s CI doesn´t offer IPv6 connectivity, so CoreDNS should be configured
# to work in an offline environment:
Expand Down Expand Up @@ -286,17 +283,6 @@ run_tests() {
"--report-dir=${ARTIFACTS}" '--disable-log-dump=true' &
GINKGO_PID=$!
wait "$GINKGO_PID"

# Return to the original directory
popd
}

# clone kubernetes repo for specific release branch
clone_kubernetes_release() {
# Clone the specific Kubernetes release branch
# Replace "release-1.31" with the desired branch
KUBE_RELEASE_BRANCH=${KUBE_RELEASE_BRANCH:-release-1.31}
git clone --single-branch --branch "${KUBE_RELEASE_BRANCH}" https://github.com/kubernetes/kubernetes.git
}

main() {
Expand All @@ -307,6 +293,13 @@ main() {
export ARTIFACTS="${ARTIFACTS:-${PWD}/_artifacts}"
mkdir -p "${ARTIFACTS}"

# Get current and n-1 version numbers
MAJOR_VERSION=$(./hack/print-workspace-status.sh | awk '/STABLE_BUILD_MAJOR_VERSION/ {print $2}')
MINOR_VERSION=$(./hack/print-workspace-status.sh | awk '/STABLE_BUILD_MINOR_VERSION/ {split($2, minor, "+"); print minor[1]}')
export CURRENT_VERSION="${MAJOR_VERSION}.${MINOR_VERSION}"
export N_MINUS_ONE_VERSION="${MAJOR_VERSION}.$((MINOR_VERSION - 1))"
export EMULATED_VERSION=$(N_MINUS_ONE_VERSION)

# export the KUBECONFIG to a unique path for testing
KUBECONFIG="${HOME}/.kube/kind-test-config"
export KUBECONFIG
Expand All @@ -327,10 +320,16 @@ main() {
res=0
create_cluster || res=$?

# Clone the specific Kubernetes release branch
clone_kubernetes_release
# Clone the previous versions Kubernetes release branch
# TODO(aaron-prindle) extend the branches to test from n-1 -> n-1..3 as more k8s releases are done that support compatibility versions
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should also think about which branches we're trying to test, if what we're trying to test is the api-server compatibility in master, it might better suit us to use the latest stable tagged patch release in the previous branch for the other components. In practice there's not usually a big distinction anyhow though.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, if we did that we could fetch binaries instead of compiling both branches from source.

Copy link
Contributor Author

@aaron-prindle aaron-prindle Nov 26, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense, given that it doesn't seem to big a distinction atm perhaps we can keep this as is for now? I created #33594 to track using precompiled binaries so perhaps we can address that in a seperate PR.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I just wanted to point that out, with the precompiled builds we have a bunch of different marker files for the subtle variations depending on what you're actually focusing on testing and how stable you want the other end of the skew.

For now 🤷, let's just get it working, but later we'll want to decide.

export PREV_RELEASE_BRANCH="release-${EMULATED_VERSION}"
git clone --filter=blob:none --single-branch --branch "${PREV_RELEASE_BRANCH}" https://github.com/kubernetes/kubernetes.git "${PREV_RELEASE_BRANCH}"

# enter the release branch and run tests
pushd "${PREV_RELEASE_BRANCH}"
run_tests || res=$?
popd

cleanup || res=$?
exit $res
}
Expand Down