Onsi Fakhouri

yes this can be done and some projects (e.g. kubernetes) organize their tests in this way. The trick is to define your specs within the `a` and `b` packages: ```...

FWIW I personally don’t usually write tests this way and just give each package its own test suite and run `ginkgo -r`. But there are certainly cases on big projects...

the workaround here would be to use `go test -c` to compile the binary you want with your desired version of Go and then pass that binary in to the...

if you’re up for working on a PR I can pull it in. I’d propose defining an environment variable that the ginkgo CLI picks up on to set the name...

give `gvm` a try. that sounds like the right solution for you.

hey @steve-hb - this makes sense to add to the v2 cli. though it's gonna be a bit before I can get to it. are you up for working on...

hey sorry for the delay - will take a look at this and share feedback.

hey - this is good but I'd like to add a test that exercises passing the context into `ReportAfterSuite`. Would you be up for adding a test to https://github.com/onsi/ginkgo/blob/master/internal/internal_integration/report_suite_test.go -...

thjanks! one last thing - rather than add `ReportAfterSuiteContext` I'd prefer to simply change `ReportAfterSuite` to accept `any` `body` (or to use generics to accept one of the two allowed...

hey @eugenenosenko - thanks for giving the generics approach a try. let’s go with `any`. It’s how much of Ginkgo operates anyway so it’s in keeping with the established pattern....