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.
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_binarytarget setup, it will create 2 actions underneath:GoCompilePkgto compile the source to archive data andGoLinkto link up the archive data into the executable binary. All is good.However, this is not the case with
go_test. For each gofoopackage, 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_testneeds 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 uniqueGoCompilePkgactions under the same//some/package/foo:foo_testtarget, 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
GoTestCompileInnerPkgandGoTestCompileOuterPkgso that we could identify them using external tooling more easily.