onsi
commented
8 months ago 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?
Hi, I know you can
go install, but I have a use case where I need to build it for a different architecture and I can'tI'm happy to throw a PR up, but I was wondering if it's possible for us to add compiled binaries to the Github release information. As a work around, I'm cloning the repo and calling
go build, but I'd rather just download binaries so that I know that all the build flags match others.