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
However, BEP and related tool logs files usually assume that we can identify a unique action from a combination of its target path, such as //some/package:target_name, and it's action mnemonic, such as GoCompilePkg.
And this is usually the case. For example, if I have a go_binary target setup, it will create 2 actions underneath: GoCompilePkg to compile the source to archive data and GoLink to link up the archive data into the executable binary. All is good.
However, this is not the case with go_test. For each go foo package, we could write an inner test file under package foo, which has access to unexported funcs and variables, that use the same package name foo. Or, we could write an outer test file under package foo_test, which has access only to the exported funcs and variables of foo.
Because of this, go_test needs to perform 2 compilation actions: one for the inner package and one for the outer package, before linking the results into the test executable binary. This results in 2 unique GoCompilePkg actions under the same //some/package/foo:foo_test target, which are hard to tell apart from looking at the BEP data and/or related tool logs attached to the BEP.
I think we should consider using a different mnemonic for these 2 actions. Perhaps GoTestCompileInnerPkg and GoTestCompileOuterPkg so that we could identify them using external tooling more easily.
The text was updated successfully, but these errors were encountered:
sluongng
added a commit
to sluongng/rules_go
that referenced
this issue
May 7, 2024
In Bazel, we use BEP https://bazel.build/remote/bep to emit the telemetry data of a build.
However, BEP and related tool logs files usually assume that we can identify a unique action from a combination of its target path, such as
//some/package:target_name
, and it's action mnemonic, such asGoCompilePkg
.And this is usually the case. For example, if I have a
go_binary
target setup, it will create 2 actions underneath:GoCompilePkg
to compile the source to archive data andGoLink
to link up the archive data into the executable binary. All is good.However, this is not the case with
go_test
. For each gofoo
package, we could write an inner test file under packagefoo
, which has access to unexported funcs and variables, that use the same package namefoo
. Or, we could write an outer test file under packagefoo_test
, which has access only to the exported funcs and variables offoo
.Because of this,
go_test
needs to perform 2 compilation actions: one for the inner package and one for the outer package, before linking the results into the test executable binary. This results in 2 uniqueGoCompilePkg
actions under the same//some/package/foo:foo_test
target, which are hard to tell apart from looking at the BEP data and/or related tool logs attached to the BEP.I think we should consider using a different mnemonic for these 2 actions. Perhaps
GoTestCompileInnerPkg
andGoTestCompileOuterPkg
so that we could identify them using external tooling more easily.The text was updated successfully, but these errors were encountered: