Expose Action tools/input_manifest inputs

[rickeylev]

Description of the problem / feature request:

ctx.actions.run() et al allow passing in "tools" and "input_manifests". Unfortunately, these values aren't exposed on Action objects,
which makes writing analysis tests to verify actions difficult/impossible.

Feature requests: what underlying problem are you trying to solve with this feature?

Specifically, to allow tests to verify that an action was passed the expected set of inputs. As an example, when a tool is passed to the action, the test needs to verify that the symlinks in the tools's runfiles are passed to the action.

IMHO, I would suggest exposing the result of ActionExecutionMetadata.getRunfilesSupplier().getMappings() on the Action objects. I'd suggest a name such as Action.input_runfiles, and the value is Map<str runfiles_dir, Map<str path_in_runfiles, File> (the first-level key is the path to a binary's runfiles, the second level key is the path of a file within the a runfiles dir)

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Simply dir() an Action instance. It doesn't have any attributes that expose the value, nor does the backing Java code expose such an accessor.

What operating system are you running Bazel on?

Linux

What's the output of bazel info release?

N/A

If bazel info release returns "development version" or "(@non-git)", tell us how you built Bazel.

N/A

What's the output of git remote get-url origin ; git rev-parse master ; git rev-parse HEAD ?

N/A

Have you found anything relevant by searching the web?

No

Any other information, logs, or outputs that you want to share?

No

[sgowroji]

Hello @rickeylev, Could you please provide more details with respect to the above request. Thanks!

[rickeylev]

As an example, lets say you have a tool, "packager", that takes other targets (including their runfiles) as inputs. So you'd have code like this:

ctx.actions.run(
  executable=ctx.executable.packager,
  args = ["--packaged_root={ctx.file.packaged.path}.runfiles"],
  tools=[ctx.attr.packaged]
)

This works just fine, but writing an analysis test to verify the action actually got the expected inputs is hard. In our example above, we'd want to verify that (1) --packaged_root flag matches the runfiles path that will be created; (2) the files under that runfiles path are what we expect (i.e. it's equal to ctx.attr.packaged[DefaultInfo].default_runfiles), and (3) The Action.inputs values contain all the necessary files from packaged.

However, in an analysis test, querying the action's inputs will just say there was a single "middleman" file as the input. These middleman files are rather opaque and magical: they're located in an obscure and internal place, they use the S/U encoding for the file names, they append "-runfiles" to their names, they kind of don't actually exist, and its some special code elsewhere that "expands" these middleman files into the set of larger inputs they represent. Lots of implementation details there that you don't really want to rely on, nor are they really of interest to me -- I don't care that there was a "middleman" thing, I just care about the path the runfiles are materialized under, the set of files under it, and the inputs available to the action.

[github-actions]

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 90 days unless any other activity occurs. If you think this issue is still relevant and should stay open, please post any comment here and the issue will no longer be marked as stale.

[github-actions]

This issue has been automatically closed due to inactivity. If you're still interested in pursuing this, please post @bazelbuild/triage in a comment here and we'll take a look. Thanks!