cquery doesn't filter ruleInputs according to used configurations

[illicitonion]

Description of the problem / feature request:

Cquery follows selects across the build graph, but does not appear to perform this filtering to the Rule.rule_input field.

Accordingly, when trying to ascertain what files may affect a target in the current configuration, irrelevant files may be returned.

For example, when trying to query the transitive affecting files of this kind of target:

java_test(
    name = "ExampleTest",
    srcs = ["ExampleTest.java"],
)

Following the rule_input fields when evaluating bazel cquery 'deps(//java/example:ExampleTest) --output=jsonproto, there's the chain:

//java/example:ExampleTest -> @bazel_tools//tools/test:xml_writer -> @bazel_tools//tools/test:xml.exe

However, when the currently configured platform is not Windows, there should be no dependency on xml.exe, as that's Window-specific.

I think it would be reasonable to have to perform some logic to do this filtering (though it just being presented completely up-front would be great), but right now I don't think it's possible to follow any algorithm to decide that xml.exe isn't actually a dependency in the current configuration...

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

Coming up with a hash for each target so that we can diff graphs across different commits of source code. See also #7962.

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

With the above BUILD file, run a bazel cquery for that target, and try determine whether @bazel_tools//tools/test:xml.exe is depended on by the target.

What's the output of bazel info release?

release 4.2.1

/cc @gregestren

[illicitonion]

Relatedly, it feels like these ruleInputs should be ConfiguredTargets not just labels - it's impossible to chase the ruleInput graph if a label is present under multiple configurations. For instance, say have a repo containing both a target using Java in the exec configuration:

java_binary(
    name = "jbin",
    srcs = ["JBin.java"],
    main_class = "JBin",
)
 
genrule(
    name = "run_jbin",
    tools = [":jbin"],
    cmd = "$(execpath :jbin) hello world > $@",
    outs = ["out"],
)

As well as a java_test which depends on a Java toolchain in the target configuration - these will both list @bazel_tools//tools/jdk:current_java_runtime as a ruleInput, but without specifying which configuration each is for, it's impossible to know which is affected by changes to host or target java toolchains. We can over-estimate and say that both are affected, but this may lead to significant over-building in the CI case.

[sdtwigg]

So, looking specifically at the ruleInputs issue, this is as-intended. It is dumping the (potential) inputs for a Rule where Rule is a loading phase (post-BUILD file processing) concept and thus has no notion of a configuration. (A ConfiguredTarget is what results from taking a Rule and applying a configuration to it so that select statements can be resolved and an implementation executed.)

Can you clarify the underlying problem? I am not very familiar with the JSON proto output format. On first glance, for cquery, it looks like it just dumps the Rule info and configuration info for each target, which may not be sufficiently disambiguating for your use case.

[illicitonion]

Can you clarify the underlying problem?
The root problem we're trying to solve here is to determine which targets Bazel thinks could have changed between two commits, so that we know what tests to run on CI, what binaries to re-deploy, etc - in order to do that, we need a list of files which, if they've changed, cause the target to have changed.

Taking the example from the original issue here, this dep chain:

//java/example:ExampleTest -> @bazel_tools//tools/test:xml_writer -> @bazel_tools//tools/test:xml.exe

By the time cquery is running, when not on Windows, Bazel knows that xml.exe is not a relevant ruleInput, because it has resolved this select:

filegroup(
  name = "xml_writer",
  srcs = select({
    "@bazel_tools//src/conditions:windows": ["@bazel_tools//tools/test:xml.exe"],
    "//conditions:default": ["@bazel_tools//tools/test:xml"],
  }),
)

Right now the code I'm writing to fingerprint each target does more work than it needs (hashing xml.exe) and will return false positives (if xml.exe has changed, it will say that the target has changed and needs re-running) - I'm trying to leverage information that Bazel already knows to avoid these two issues.

[purkhusid]

@illicitonion I'm curious if the tool you are building is open source? We currently use https://github.com/Tinder/bazel-diff but I'm interested in seeing what approaches people are using to solve the Bazel diff problem.

[illicitonion]

@illicitonion I'm curious if the tool you are building is open source? We currently use https://github.com/Tinder/bazel-diff but I'm interested in seeing what approaches people are using to solve the Bazel diff problem.

It's not currently, but we're hoping to open source it soon. Roughly our approach is to, at both the before and after commit, cquery deps(...) and follow all of the ruleInputs edges, hashing rules and files appropriately. Watch this space :) (and very happy to chat, e.g. on the Bazel slack)

[gibfahn]

I'm curious if the tool you are building is open source? We currently use Tinder/bazel-diff but I'm interested in seeing what approaches people are using to solve the Bazel diff problem.

We have now open-sourced this, it's at https://github.com/bazel-contrib/target-determinator