Hi @itaysk, yeah, not ready to merge yet. I opened the PR early to see the workflow in action, but marked as WIP when I realised more is needed.

I got it to that point and needed to think about how to deal with the fact Kube is required for the two suites to work. I actually just got an idea, well, something I've seen elsewhere, it's to check if k8s is available and if not, spin up a local k3s or kind.

I was also researching if we can make use of additional service containers to spin up a cluster. But if not, it'd probably be best to do something like that in bats setup/teardown, or if not possible then in Makefile before launching bats. What do you think about that?

As for jq, it comes as part of standard virtual environment provided on the GitHub runners.

Right, sorry I missed the [WIP] in the title!
Integrating kind as additional service is fantastic. Let me know if you prefer to merge this one with just unit/component tests and work on the e2e test on a separate PR, or to continue working on this PR.

That's a good point, since it increases the scope it makes sense to separate the tests requiring kind into a separate PR. I'll update this later today to split it.

Hi @itaysk, I updated this change to limit the scope to only running the basic tests and opened #15 for extending it to run all tests including those that require k8s. I also found someone already created an action for setting up kind/minikube in test env so this should be easier to add than I previously assumed 🎉 😄

Anyway, this one passes now so it should be good for another review. Thanks!

good work, thanks!
just heads up that when we'll start using goreleaser soon, this workflow will change accordingly (use the goreleaser action).

Taking back the following:

just heads up that when we'll start using goreleaser soon, this workflow will change accordingly (use the goreleaser action).

This workflow is for CI, and goreleaser is for CD. I've added go releaser and left this workflow intact.