--run_under discards analysis cache

[Profpatsch]

Description of the problem / feature request:

When I use bazel run --run_under //sometarget and then bazel build //sometarget after:

INFO: Build option --run_under has changed, discarding analysis cache.

Which completely discards all repository rules as well.

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

Just trying to run stuff to test artifacts.

--run_under is not even an option to build, so why does it invalidate the analysis cache. It’s also only relevant to the execution of a generated artifact, so I don’t see why it should influence the build at all.

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

as above

What operating system are you running Bazel on?

Nixos 20.01

What's the output of bazel info release?

bazel info release
INFO: Invocation ID: 453a0027-23cd-4bbf-a227-2f5045d96fbd
release 2.0.0- (@non-git)

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

nixpkgs

Have you found anything relevant by searching the web?

doesn’t seem to be an issue in the tracker

[gregestren]

It looks like this is used in analysis, like:

bazel/src/main/java/com/google/devtools/build/lib/analysis/RunfilesSupport.java

Lines 103 to 105 in a0e7b67

	// Adding run_under target to the runfiles manifest so it would become part
	// of runfiles tree and would be executable everywhere.
	RunUnder runUnder = ruleContext.getConfiguration().getRunUnder();

bazel/src/main/java/com/google/devtools/build/lib/analysis/configuredtargets/RuleConfiguredTarget.java

Lines 157 to 160 in a11e2d0

	// If this rule is the run_under target, then check that we have an executable; note that
	// run_under is only set in the target configuration, and the target must also be analyzed for
	// the target configuration.
	RunUnder runUnder = ruleContext.getConfiguration().getRunUnder();

Sending to @sdtwigg for triage and prioritization. He's been looking at similar territory. How tightly entwined is run_under to the process of constructing a viable build graph?

[Profpatsch]

Correction: It doesn’t seem to throw away my repository rule caches, just the in-memory cache of the target graph.

[sdtwigg]

Currently, run_under is under CoreOptions, not TestOptions, so it will not benefit from --trim_test_configuration.

As noted, references to it are very sparse so it may be possible to refer to it only in the TestActionBuilder and thus this could be moved to the TestConfiguration. This would then solve the related issues under the umbrella of 'productionizing' trim_test_configuration.

(e.g. "what if someone has run_under in a select()?", "what if someone tries to transition run_under?", etc.)

[gregestren]

Stephen - didn't we find out that there are some real references that make it non-trivial to extract out?

If it only affects actions top-level targets (vs. everything in the graph), I think that would open up better options.

[ulfjack]

The --run_under option also applies to the run command when used with binary targets, not just to test targets. If run_under refers to a target, then it must be analyzed in the analysis phase. In other cases, it may be possible to rewrite the code to inject the flag in the execution phase instead. We do something similar for inherited env variables.

[pauldraper]

If run_under refers to a target

What does this mean? How can it refer to a target?

[voxeljorge]

The most common workaround recommended for running a bazel target with bazel run under the current working directory is to use --run_under: #3325

Having --run_under break the analysis cache in these cases seems unnecessary and counter-intuitive. One example of a case that is problematic is where one might have some tool scripts which call bazel run --run_under="cd $PWD && exec" "$@" so that you can hook up an editor to run tools from bazel targets hermetically. It's difficult to control how often editors call tools like this, so in effect the analysis cache is just always broken.

[alexeagle]

FYI I wrote about the best workaround I know of, see https://blog.aspect.build/run-tools-installed-by-bazel

bazel 2>/dev/null build "$target" && exec $(bazel info execution_root)/$(bazel 2>/dev/null cquery --output=files "$target") "$@"