/test

Should we be dropping 1.30 and 1.31 while we're at it? I'm wondering about the number of permutations we end up running for the same tests.

I see this as a non-blocking comment, which can be addressed separately (but is very valid). Merging this change.

Should we be dropping 1.30 and 1.31 while we're at it? I'm wondering about the number of permutations we end up running for the same tests.

According to https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html extended support by EKS of k8s 1.30 is until july 2026 so that's why I kept it here

I see, but also 1.29 is there and we don't test that. I wonder what value are we getting out of extra permutations and whether we should aim for a smaller set of versions that is representational of the full set without requiring more iterations through the tests. For instance we might consider running tests against the oldest supported and the two newest supported. I raise this because the PR here adds a new permutation without removing an old one, so we're increasing the number of tests we run.

The goals of reducing the number of permutations would be to reduce the likelihood of unrelated failures due to running the same tests many times, and also reduction in costs (monetary and otherwise) from additional test runs. If we can get a good sense for coverage with fewer test runs, that's worth considering IMO.

I see, but also 1.29 is there and we don't test that. I wonder what value are we getting out of extra permutations and whether we should aim for a smaller set of versions that is representational of the full set without requiring more iterations through the tests. For instance we might consider running tests against the oldest supported and the two newest supported. I raise this because the PR here adds a new permutation without removing an old one, so we're increasing the number of tests we run.

The goals of reducing the number of permutations would be to reduce the likelihood of unrelated failures due to running the same tests many times, and also reduction in costs (monetary and otherwise) from additional test runs. If we can get a good sense for coverage with fewer test runs, that's worth considering IMO.

Completely agree on the reasons of reducing the number of permutations. My first thought was that keeping the 1.30 should be okay since it's only going to run on the schedule part (once a day IIRC) and not bother all the pull request with it.

If you feel we could part ways with 1.30 & 1.31 without impacting the coverage too much, I'm all for it. After all, if anybody has an issue with a still ongoing version of k8s on EKS that we're not testing on a daily basis, there's always the possibility to open an issue on the repo.

My first thought was that keeping the 1.30 should be okay since it's only going to run on the schedule part

Ah, TIL. It wasn't obvious to me from the PR that these different versions are targeted differently by other CI jobs. SGTM.

My first thought was that keeping the 1.30 should be okay since it's only going to run on the schedule part

Ah, TIL. It wasn't obvious to me from the PR that these different versions are targeted differently by other CI jobs. SGTM.

IIRC it's the "default" set in the matrix that will be run in the PRs, the other entries are for the scheduled workflows.

@Artyop I marked this as a backport/author as the matrix of the v1.18 and v1.17 are diverged from the main and I'm not certain which parameters should be kept/removed.

We typically wouldn't backport new platform support to older releases.