You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When demoing Kubewarden internally and externally, it would be helpful to have ready-made resource definitions in Yaml to use.
Acceptance criteria
Search and reuse if possible existing art and testsuites that already provide insecure resource examples.
Refactor E2E tests so individual testcases, their code, and the expected results are together. For example, a single folder for mutating requests or policies would contain its .bats file, showcasing how the test is run and what to expect, and the needed resource .yaml to trigger it.
Add more examples of insecure resources (example: a Pod with an aws secret key, a Job with privileged containers, etc). These examples should be easily applied to a cluster: in Yaml format, with a defined namespace that is the same for all the examples, and so on.
Policy e2e tests, which use kwctl run and the admission Request JSON, sadly cannot be reused as full Kubewarden E2E tests.
Still, they are a big testcase corpus that we aren't taping into. It could be possible to, from resource definitions in yaml, craft those admission requests programatically, and then consume the admission requests JSONs with kwctl run as we do now. Maybe with something like kubectl create foo bar --dry-run=server -v=9.
If that would be possible, we could reuse the yaml resource definitions as examples or in Kubewarden full E2E testcases.
The text was updated successfully, but these errors were encountered:
When demoing Kubewarden internally and externally, it would be helpful to have ready-made resource definitions in Yaml to use.
Acceptance criteria
kwctl run
and the admission Request JSON, sadly cannot be reused as full Kubewarden E2E tests.Still, they are a big testcase corpus that we aren't taping into. It could be possible to, from resource definitions in yaml, craft those admission requests programatically, and then consume the admission requests JSONs with
kwctl run
as we do now. Maybe with something likekubectl create foo bar --dry-run=server -v=9
.If that would be possible, we could reuse the yaml resource definitions as examples or in Kubewarden full E2E testcases.
The text was updated successfully, but these errors were encountered: