Hey @dmihalcik-virtru thanks for this PR. We will be taking a different approach.
Like xtest, the current e2e tests for otdfctl similarly spin up the platform and its resources in the background to run end to end tests against. This is our ideal to own success/failure of the testing:
otdfctl PRs test the PR branch against the latest platform main
platform PRs test the platform PR branch against the latest otdfctl
add a workflow_call trigger to otdfctl and make the e2e test a separate job so its reusable
I think we can likely forgo otdfctl within xtest as a separate repo and make each job's commit shas dynamic inputs so we have:
one set of tests for the client PEP
tests that remain close to the code (which means new features get new e2e tests immediately rather than in follow-up PRs)
the platform testing backwards/forwards compatibility
the CLI testing backwards/forwards compatibility
deduplication of tests with only one repo
two places to look when there are test failures instead of 3
simultaneous test updates with logic changes in the CLI when breaking changes are required (rather than follow-on PRs and ignored pipeline functionalities to get past intentional breaking changes)
Hey @dmihalcik-virtru thanks for this PR. We will be taking a different approach.
Like xtest, the current e2e tests for
otdfctlsimilarly spin up the platform and its resources in the background to run end to end tests against. This is our ideal to own success/failure of the testing:I think we can likely forgo
otdfctlwithinxtestas a separate repo and make each job's commit shas dynamic inputs so we have: