You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Does this issue reproduce with the latest releases of all the above?
Yes
What operating system and processor architecture are you using?
linux/amd64
Any other potentially useful information about your toolchain?
What did you do?
For reasons, we have an internal library that heavily depends on go binary (it runs go commands via os/exec, etc.). In its provided test lib, when setting up a test it also depends on the go binary to do the setup.
Without bazel, it could just assume go is in $PATH and run it blindly. But with bazel that assumption is broken and it needs to know where to find the go binary. This isn't a problem when developers run unit tests locally because we can still assume they have go in $PATH even if they run bazel to build/test locally, but it's a problem for CI because on CI we use a bazel based docker image without go in $PATH.
Thus why it would be great if rules_go can inject that info via some environment variable, so it can gets that info via env var (only needed in tests if we don't want to inject it everywhere).
I tried to check whether go toolchain itself does this, with test code to print everything from os.Environ, and found out that $_ would be pointing to the go binary when running go test.
Since this appears to be a very special case, how about adding a Go SDK to the runfiles of your tests and then passing its go binary to the test?
That's something you can do without requiring a rules_go change. Even if we wanted to, we couldn't just ship a full Go SDK with every test without regressing performance for everyone.
What version of rules_go are you using?
0.50.1
What version of gazelle are you using?
0.39.0
What version of Bazel are you using?
7.3.2
Does this issue reproduce with the latest releases of all the above?
Yes
What operating system and processor architecture are you using?
linux/amd64
Any other potentially useful information about your toolchain?
What did you do?
For reasons, we have an internal library that heavily depends on go binary (it runs go commands via
os/exec
, etc.). In its provided test lib, when setting up a test it also depends on the go binary to do the setup.Without bazel, it could just assume
go
is in$PATH
and run it blindly. But with bazel that assumption is broken and it needs to know where to find thego
binary. This isn't a problem when developers run unit tests locally because we can still assume they havego
in$PATH
even if they run bazel to build/test locally, but it's a problem for CI because on CI we use a bazel based docker image withoutgo
in$PATH
.Thus why it would be great if rules_go can inject that info via some environment variable, so it can gets that info via env var (only needed in tests if we don't want to inject it everywhere).
I tried to check whether go toolchain itself does this, with test code to print everything from
os.Environ
, and found out that$_
would be pointing to the go binary when runninggo test
.e.g. With this test code:
via
go test
it prints out:but via
bazel test :test_test
it prints out something else:What did you expect to see?
What did you see instead?
The text was updated successfully, but these errors were encountered: