Make sure to use random component names when copying sample Devfiles in integration tests#6504
Conversation
This will help prevent conflicts when isolation is not possible (for example on Podman) For consistency, next step would be not to use 'odo init --devfile-path', but instead rely on the updated helper.CopyExampleDevfile function everywhere.
✅ Deploy Preview for odo-docusaurus-preview canceled.
|
…ocalhost regardless of exposure' test
|
Kudos, SonarCloud Quality Gate passed!
|
/override OpenShift-Integration-tests/OpenShift-Integration-tests Flaky E2E test (reported in #6463 ) |
|
@rm3l: Overrode contexts on behalf of rm3l: OpenShift-Integration-tests/OpenShift-Integration-tests DetailsIn response to this:
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. |
|
/test v4.11-integration-e2e Tests failing due to user no longer being authenticated. |








What type of PR is this:
/kind tests
/area testing
What does this PR do / why we need it:
This updates the
helper.CopyExampleDevfilefunction to accept a parameter that allows performing operations on the destination Devfile (like setting itsmetadata.name). This way, callers are able to pass a unique random component name.Using a random name helps prevent conflicts when isolation is not possible (for example on Podman). This will allow fixing the Podman tests in #6499.
For consistency, the next step could be not to use
odo init --devfile-path /path/to/example/devfile(so as not to depend on theodo initcommand), but instead rely on the updatedhelper.CopyExampleDevfilefunction everywhere. But this can be done in a subsequent PR.Which issue(s) this PR fixes:
—
PR acceptance criteria:
Unit test
Integration test
Documentation
How to test changes / Special notes to the reviewer: