Description of the feature request:

As noted in a comment on #1054, Starlark rules can access volatile-status.txt as ctx.version_file and stable-status.txt as ctx.info_file, but there is no way for a Starlark rule to observe the --stamp flag setting to know if the rule should access the files or not.

What underlying problem are you trying to solve with this feature?

I want to write Starlark rules that do not access the status files unless the user specifies the --stamp setting.

Because of issues like #10075 and #10177 it is important that unstamped builds are shielded from any access to the status files:

• Remove system specific information from stable-status.txt #10177 breaks all caching when you access stable-status.txt even if you set your workspace status command to /bin/true.
• Working around Bazel remote-caching does not properly treat volatile-status as if it never changes #10075 forces us to use no-remote-exec on our stamped actions that access volatile-status.txt, which is a bottleneck for remote builds.

I tried using a custom build flag as a work-around to propagate my own version of the stamp setting, but it causes all outputs through transitions to change their output path and destroys all caching -- even on targets that don't depend on the new stamp-like setting.

What operating system are you running Bazel on?

macOS and Linux

What's the output of bazel info release?

release 3.0.0