Join GitHub today
E2E settings #69105
What this PR does / why we need it:
As described in issue #66649, the goal is to make
There's also the stalled effort to support a configuration file format. Viper was chosen for that years ago, but then existing tests were never modified to retrieve options from Viper. Note that Viper might not be the right tool for the job. Other components (kubeadm, see #66649 (comment)) also need something and the trend seems to go towards a Kubernetes-specific implementation.
This PR avoids making tests depend on Viper, it just uses Viper under the hood. This means that it could get replaced later without changing tests.
The approach suggested in this PR is (see comment in test/e2e/test_context.go):
Which issue(s) this PR fixes (optional, in
Special notes for your reviewer:
This is a subset of PR #68483.
I've updated the Viper config support:
@timothysc I think I addressed the review comments, but please check.
[APPROVALNOTIFIER] This PR is APPROVED
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:
Approvers can indicate their approval by writing
2 similar comments
Oct 10, 2018
18 checks passed
I came across this today and I was surprised that UpgradeTarget and UpgradeImage are not considered core to the framework that runs all tests. If different tests have different notions of the upgrade target and image, they aren't likely to work well together.
referenced this pull request
Mar 21, 2019
This was referenced
Mar 22, 2019
This is now the sole consumer of viper, after #76780 viper will be the sole consumer of afero; viper is already the sole consumer of hashcorp/hcl (at least).
How is this actually used? Do we need anything more than yaml & json support? My experience has been that it's easier to just write a parser, rather than using viper...
i think that viper support in the e2e framework was a mistake.
something that i proposed to @timothysc is that we simply start building a separate V2 binary e.g.
if we redo the e2e suite I'd love to see a _lot_ more redone than the flags :^)…
On Thu, Apr 18, 2019 at 11:07 AM Lubomir I. Ivanov ***@***.***> wrote: i think that viper support in the e2e framework was a mistake. though removing it now will probably break consumers. something that i proposed to @timothysc <https://github.com/timothysc> is that we simply start building a separate V2 binary e.g. e2e-suite2.test and re-do it's flags. the current flags for the suite are unmanageable. similar was done in the case of kubetest -> kubetest2. as a side note, this type of piping of config fields to CLI flags was briefly discussed during this week's WG component standard meeting with @mtaufen <https://github.com/mtaufen> and @stealthybox <https://github.com/stealthybox> . — You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub <#69105 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHADK7RNSW32BKOQTJU75DPRC2HHANCNFSM4FXL73MQ> .