Release Binaries about ginkgo HOT 1 OPEN

hey @drewgonzales360 - I've resisted going down this path for a few reasons:

Most importantly: it's important that the version of the ginkgo cli and the ginkgo library match exactly. The contract between the cli and the library is not subject to semver and can change at any time. today the recommendation is to go install or, even better, go run github.com/onsi/ginkgo/v2/ginkgo ... as that will pick up the same version of ginkgo as the library in go.mod. Decoupling the two could be problematic and potentially confusing to users.

Secondarily: I've never thought this would be necessary. Ginkgo runs tests and so it either needs to compile the tests (in which case the go toolchain needs to be present on the machine anyway, so we can always go run or go install the ginkgo cli as mentioned above). Or Ginkgo needs to be pointed at a precompiled test binary. But if the user can compile a test binary with the correct GOARCH and GOOS then they can correctly compile the ginkgo cli of the correct and ship it to their target platform.

So I suppose I'd love to learn more about your usecase, given that second point. What are the reasons you can't compile ginkgo on demand or at the same time that you precompile your test binary?

from ginkgo.