-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
source.CallExprArgs fails to open target source file when run under bazel #274
Comments
I'm tracking the |
Looking at the env vars under
There's also:
And this matches what's documented here: https://bazel.build/reference/test-encyclopedia So my new recommendation would be that, when the file paths are relative, we attempt to join the file path to |
Thanks for opening this issue! Reading the env vars set by Bazel sounds like a good approach, as does the warning message to include the go source files when |
When running under
bazel test
, thesource.CallExprArgs
function will fail to open the target source file.I have a minimal reproducer here: https:/cstrahan/assert_bazel_repro
For posterity (and convenience), here's the code from that repo:
When I invoke
go test
directly, I see:The
repro_test.go:32: assertion failed: a is not b: a should equal b
looks good 👍However, when run under bazel:
Instead of showing the user defined assertion message, we see that
source.CallExprArgs
chokes when trying to opensome_package/repro_test.go
:This makes sense, as the effective path to be opened will be:
It's probably more immediately apparent if we let
SRC_ROOT=/private/var/tmp/_bazel_charles/99cf13450b07a7c7594bbbe785fbd4ef/sandbox/darwin-sandbox/177/execroot/__main__/bazel-out/darwin_arm64-fastbuild/bin/some_package/some_package_test_/some_package_test.runfiles/__main__/
:That ought to be:
I don't know why the
filename
thatruntime.Caller
returns (here) is an absolute path undergo test
, but a relative path underbazel test
. I think I'll poke therules_go
devs to see if there's anything they can do from their end to make this consistent across both environments.At any rate, it seems that a workaround shouldn't be too difficult to implement within
gotest.tools
:var origWorkingDir, _ = os.Getwd()
(in case the test codeChdir
s)runtime.Caller
is relative, joinorigWorkingDir
and the basename offilename
.Admittedly, that falls down if
Assert
(or whatever) is called from somewhere other than directly within the package under test.Workarounds aside, it would be nice if this library would gracefully handle failure to resolve original source file. My proposal would be to print the user supplied assertion message, and then give a warning. I would bet that 99% of people running into this would be
bazel
users, so I think it would be worthwhile having a friendly targeted message, also giving them a heads up that they might be forgetting to add their source files to theirgo_test.data
param, as I did here: https:/cstrahan/assert_bazel_repro/blob/575739d5201400c10f634053a5eb365f054d4dd4/some_package/BUILD.bazel#L7A hint to look at https:/bazelbuild/rules_go#how-do-i-access-go_binary-executables-from-go_test would be great.
Would you be interested in accepting a PR to implement some or all of the above?
Thanks! 😄
The text was updated successfully, but these errors were encountered: