Add e2e variant that modifies common environment variables #688
Conversation
openshift-ci
bot
added
the
approved
|
/retest |
Is there any downside to running both? Would they run in parallel? Or sequentially? To me it seems having both provides more value, unless it takes a ton more time and/or there is overlap between the two. |
|
I think they would run serially. I'm not sure there's a downside to running both, personally, other than time, but I'm not overly offended by the e2e duration at the moment. I'm keeping the options open for now. |
|
At the very least, having it in repo means I could just as easily run it locally to ensure we're testing some degree of the pipeline's invocation. |
Signed-off-by: Jose R. Gonzalez <jose@flutes.dev>
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: acornett21, jomkz, komish 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 |
Part of #646
The pipeline is using environment variables to configure preflight. No flags.
To a certain extent, we have a degree of testing ensuring that the environment variables (that make it to viper) end up in our runtime configs. What they do, however, could probably use more coverage.
Ideal case would be to run the pipeline's tekton task, but that requires an entire cluster + tekton installed. For the moment, I've added a variant of our existing e2e script that modifies things using the environment. Those that can be tested somewhat reliably have been added to this script.
I'm considering either running this in lieu of our current e2e (which requires changing some of our e2e tests in openshift/release), or running it as a second task. As of right now, it does not run in our e2e pipeline.
I was able to get this to pass using the default operator listed in the script.
Signed-off-by: Jose R. Gonzalez jose@flutes.dev