mako.Setup tries to get the Mako benchmark id by reading a Mako config file from kodata. This is a totally reasonable approach, but it doesn't work for eventing because there's a single image that's used for multiple benchmarks. The kodata for the single image can't have all the benchmark ids, especially since we'll have tests in both eventing and eventing-contrib.
Eventing may eventually refactor tests to use the layout mako.Setup expects, but for now it's blocking Mako support.
I'd like an alternate mako setup method (with a different name) that can choose a benchmark id at runtime instead of compile time. Ideas for this:
- take a map of environment strings to benchmark ids and pass the map in as an env var or flag
- create a configmap containing all the benchmark config files, mount it in the container, and use it similarly to kodata
/area test-and-release
/kind feature
mako.Setuptries to get the Mako benchmark id by reading a Mako config file from kodata. This is a totally reasonable approach, but it doesn't work for eventing because there's a single image that's used for multiple benchmarks. The kodata for the single image can't have all the benchmark ids, especially since we'll have tests in both eventing and eventing-contrib.Eventing may eventually refactor tests to use the layout
mako.Setupexpects, but for now it's blocking Mako support.I'd like an alternate mako setup method (with a different name) that can choose a benchmark id at runtime instead of compile time. Ideas for this:
/area test-and-release
/kind feature