multirun(), command(): export RUNFILES_* envvars

[laszlocsomor]

When binary (or test) "A" data-depends on binary
"B", Bazel merges B's runfiles into A's and only
generates a runfiles manifest/directory for "A"
but not "B". To let "B" find its runfiles, "A"
must export the "RUNFILES_*" envvars first. This
is common for tests (A) that run binaries (B) with
data-dependencies.

The multirun() and command() rules fall prey to
this runfiles-merging. To run *_binary targets,
they must discover and export the runfiles
envvars.

Fixes the bug in bazelbuild/bazel#7774

[laszlocsomor]

/cc @Globegitter

[ash2k]

@laszlocsomor
Hey, thanks for the PR! Could you sign the CLA please https://github.com/atlassian/bazel-tools#contributing ?

Would be great to have the mechanism fully documented somewhere i.e. how could I have written this myself without trial and error and reverse engineering how runfiles work?

[laszlocsomor]

@ash2k : Where can I read the text of the CLA?

Runfiles are documented poorly. I plan to improve the docs when I have some time: bazelbuild/bazel#6402

I don't know how you could've written it yourself. I'm a domain expert and it took me hours to figure out the problem.

[ash2k]

@laszlocsomor the CLA text is shown after the email verification step on the docusign website. Sorry for the inconvenience, but that's the process. If you work for Google, a corporate CLA may have been signed already (e.g. we have a CLA signed with Google for our contributions), but I cannot check right now.

[ash2k]

Improving documentation around runfiles would be great. All the fields in the runfiles object need more explanation and examples. Also see bazelbuild/bazel#3015

[laszlocsomor]

@ash2k : Thanks for the approval! I don't yet know if I'm allowed to sign the CLA, so I need to put this PR on hold. I'll ping the thread when I know more.

[laszlocsomor]

I signed it!