Instead of overriding the env variables add them to the environment.

[jbtk]

Before this change if needed to pass additional env variable to the ginkgo tester it would remove other variables. With this change it adds variables specified in the commandline.

[k8s-ci-robot]

Welcome @jbtk!

It looks like this is your first PR to kubernetes-sigs/kubetest2 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/kubetest2 has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @jbtk. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

[MushuEE]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jbtk, MushuEE

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [MushuEE]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[MushuEE]

/ok-to-test

[jbtk]

It seems that the test is setting env variable to use bazel 5.3.0 and then something else expects that bazel version is >= 5.4.0.

• the version is set here: https://github.com/kubernetes-sigs/kubetest2/blob/master/kubetest2-gce/ci-tests/buildupdown.sh#L31 - is this actually needed? Can it be bumped up to 5.4? It is likely that this is caused by this change- as it prevents the env from being fully overwritten.

[jbtk]

Actually I can repro this problem locally without my change. Is there any place where these test runs as continues integration to see whether this happens there as well?

I will update the version to 5.4.0 and let it retest.

[k8s-ci-robot]

New changes are detected. LGTM label has been removed.

[k8s-ci-robot]

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

Test name	Commit	Details	Required	Rerun command
pull-kubetest2-gce-build-up-down	225b6ae	link	true	/test pull-kubetest2-gce-build-up-down

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.

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-sigs/prow repository. I understand the commands that are listed here.

[jbtk]

I pushed a new version, but it was only caused by some changes in my local repo. I moved the change of the version to a separate PR (#265). Please let it test and approve if it is ok. Once this is done I will update this version so that the test passes.

[BenTheElder]

Before this change if needed to pass additional env variable to the ginkgo tester it would remove other variables. With this change it adds variables specified in the commandline.

Those values should be added as flags to the tester ..?

The not passing through env is by design. It makes tests more reproducible.

[jbtk]

The cl came from the fact that I struggled to run tests in legacy mode (see issue for details: #263).

It seems that kubetest2 sets a various env variables and therefore passing one additional and clearing them breaks the test (at least this is what happens in the legacy mode). I am not sure whether expecting person who wants to add/update one env variable to know how to specify all of them is a good solution (though I might be missing something - as you see in the issue running tests was a journey for me because I do not know the ecosystem well enough). From my testing it seemed that passing empty does not clear previously existing env and passing a single one does clear them and sets only the defined env variable. This is confirmed in the Env field of the Cmd: https://cs.opensource.google/go/go/+/refs/tags/go1.22.3:src/os/exec/exec.go;l=163. So currently we are actually passing all the env vars unless user specifies env flags and then we only set what is specified (and clear what would be normally passed otherwise).

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle stale
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle rotten
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[jbtk]

/remove-lifecycle stale

Since I explained why I proposed this PR and did not get any response I am restarting the clock. If I do not get any answer in 30d I will just close this pr.

[jbtk]

/remove-lifecycle rotten