[APPROVALNOTIFIER] This PR is NOT APPROVED

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

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

@danwinship: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

for ad-hoc jobs we use to make a copy of this script and parametrize it accordenly , see https://github.com/kubernetes/test-infra/tree/master/experiment , specifically

• https://github.com/kubernetes/test-infra/blob/master/experiment/kind-multizone-e2e.sh
• https://github.com/kubernetes/test-infra/blob/master/experiment/kind-logs-e2e-k8s.sh
• https://github.com/kubernetes/test-infra/blob/master/experiment/kind-detect-local-e2e.sh

then setting the job is something like

https://github.com/kubernetes/test-infra/blob/a190756db87de069764a104f1c024ecdd052257b/config/jobs/kubernetes/sig-network/sig-network-kind.yaml#L217-L263

This avoid growing the surface of this script and end in a situation like we had in-tree with the cluster-up scripts.

Let's see what @BenTheElder thinks about this too,

Ah, I should have looked more carefully at the various jobs...

Does e2e-k8s.sh ever get bugfixes? It seems like this approach would lead to divergence between the different jobs. At least, maybe there should only be one fork of e2e-k8s.sh in test-infra, that handles all the variants?

Anyway, I'm happy to move this to test-infra. I doubt it would turn out to be that generically useful in the future.

At least, maybe there should only be one fork of e2e-k8s.sh in test-infra, that handles all the variants?

this script is a wrapper to launch a kind cluster and run the ginkgo tests, the only changes it had was to add some new env variables to parametrize it.
If we use one to handle variants then it needs an owner, the risk of adding a bug or some change that impact other jobs exist.
If we fork and make it only per job, then the only risk is for that specific job that has a clear owner and once the job is configured it can not fail unless kind or kubernetes e2e test make a breaking change ... but then this specific job will be the less of our problems