Onsi Fakhouri

hey @kolyshkin sorry for the confusion. the [documentation covers how Ginkgo runs specs in parallel](https://onsi.github.io/ginkgo/#mental-model-how-ginkgo-runs-parallel-specs) so i recommend reading that. in brief, by default invoking `ginkgo` launches one process that...

hey @guettli - since Ginkgo generates its own test tree (and long predates more recent go test improvements, including go test's json output) it doesn't automatically hook into go test's...

thanks for reporting this. it's fixed now in v2.23.0

hey there - my first question was gonna be "how could `ginkgo --dry-run` take that long??" but then I cloned your repo and saw that... in fact... the build times...

hey thanks for bringing this up and proposing a solution (and including a PR!) i'm open to the approach you've taken though we'll need to add some documentation to make...

the more i think about it the less confident i am about an `omit` tag that controls output without also controlling equality. While I wholeheartedly agree about the irritating reality...

Thanks for reporting this - I don't know who/how the debian packages are maintained but it seems odd to me that installing ginkgo ends up running all the tests. There's...

ah, thanks for clarifying. yes this is likely due to a slow build machine. The test is a bit too finnicky about the measured duration so I'm pushing a fix...

v2.20.1 has the fix. I don't generally backport bugfixes to prior minor releases, however, so this will not resolve flakiness issues on older version of Ginkgo.

sounds good. let me know if you see it flake again (i wasn't able to reproduce it locally but am pretty sure this is the issue).