cquery missbehaves with aspects and output groups

[ansonos]

Description of the bug:

Using an aspect and an output group (setting one explicitly/removing default), to change "into what" a target is build, will result in an empty output when using cquery --output=files.

bazel build --output_groups=og --aspects=path%aspect //target
bazel cquery --output_groups=og --aspects=path%aspect //target --output=files

• aspect creates a file
• og is the output group used by aspect
• Without overwriting the output_group the original/non-aspect file is shown.

Maybe I'm holding the tool wrong; I didn't find another way to figure out where bazel generated output from a bazel build invocation lands.

Which category does this issue belong to?

Core

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

No response

Which operating system are you running Bazel on?

linux

What is the output of bazel info release?

release 8.0.0rc8

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

No response

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

No response

If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.

Same behaviour as 7.4.0 - didn't check earlier.

Have you found anything relevant by searching the web?

No response

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

No response

[ansonos]

I tried to get the output path via starlark:expr --starlark:expr="' '.join([f for f in target.files.to_list()])" but did not get the right file either.
Maybe I'm not selecting the right output group?

[ansonos]

cquery seems to apply the aspect (verified via print). The output group or the aspect provider however can not be found / accessed.

[fmeum]

@gregestren Would you expect the information about output groups created by aspects to be available in cquery?

[gregestren]

Immediate intuition is no, since cquery doesn't parse aspects as thoroughly as configured targets: see #16310 and #16310 (comment).