Changes in workspace_status output do not invalidate cached artifacts which take ctx.version_file as input

[tnarg]

Description of the problem / feature request:

Changes to the output of workspace_status_command do not invalidate cached outputs which specify ctx.version_file as an input.

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

To illustrate the issue I've created a small demonstration git repository, test_volatile_status. The repository includes a workspace with a single skylark rule, test_volatile_status which copies ctx.version_file to an output, and lists ctx.version_file as an input. The workspace_status_command includes information about the state of the git repository. The first step is to build the target, //:artifact. Then you can switch to another branch which includes an additional commit which changes the output of the workspace_status_command. Building //:artifact on the new branch DOES NOT invalidate the cached //:artifact output, but DOES result in an updated bazel-out/volatile-status.txt.

Here are the exact steps to reproduce the issue using the repository:

laptop:tmp tnarg$ bazel version
Build label: 0.15.0-homebrew
Build target: bazel-out/darwin-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Tue Jun 26 12:42:27 2018 (1530016947)
Build timestamp: 1530016947
Build timestamp as int: 1530016947
laptop:tmp tnarg$ git clone https://github.com/tnarg/test_volatile_status.git
Cloning into 'test_volatile_status'...
remote: Counting objects: 12, done.
remote: Compressing objects: 100% (7/7), done.
Unpacking objects: 100% (12/12), done.
remote: Total 12 (delta 1), reused 12 (delta 1), pack-reused 0
laptop:tmp tnarg$ cd test_volatile_status/
laptop:test_volatile_status tnarg$ bazel build //:artifact
Starting local Bazel server and connecting to it...
.............
INFO: Analysed target //:artifact (4 packages loaded).
INFO: Found 1 target...
Target //:artifact up-to-date:
  bazel-bin/artifact.txt
INFO: Elapsed time: 3.538s, Critical Path: 0.04s
INFO: 0 processes.
INFO: Build completed successfully, 1 total action
laptop:test_volatile_status tnarg$ cat bazel-bin/artifact.txt
BUILD_TIMESTAMP 1531334603
GIT_STATUS c3038c0ce8cee5dde5d0a63ed8dc600dd40b4b69
laptop:test_volatile_status tnarg$ git checkout part2
Branch part2 set up to track remote branch part2 from origin.
Switched to a new branch 'part2'
laptop:test_volatile_status tnarg$ git rev-parse HEAD
2daf6525fbc022b068020c7aa409d31347c83c76
laptop:test_volatile_status tnarg$ bazel build //:artifact
INFO: Analysed target //:artifact (0 packages loaded).
INFO: Found 1 target...
Target //:artifact up-to-date:
  bazel-bin/artifact.txt
INFO: Elapsed time: 0.190s, Critical Path: 0.03s
INFO: 0 processes.
INFO: Build completed successfully, 1 total action
laptop:test_volatile_status tnarg$ cat bazel-bin/artifact.txt
BUILD_TIMESTAMP 1531334603
GIT_STATUS c3038c0ce8cee5dde5d0a63ed8dc600dd40b4b69
laptop:test_volatile_status tnarg$ cat bazel-out/volatile-status.txt
BUILD_TIMESTAMP 1531339047
GIT_STATUS 2daf6525fbc022b068020c7aa409d31347c83c76

What operating system are you running Bazel on?

macOS High Siera 10.13.5

What's the output of bazel info release?

release 0.15.0-homebrew

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

https://github.com/tnarg/test_volatile_status.git

[ashi009]

volatile status won't trigger a rebuild, only stable ones will.

Please prefix your status with STABLE_ and try again.

https://docs.bazel.build/versions/master/user-manual.html#flag--workspace_status_command

[tnarg]

If volatile status isn’t a valid input, it seems like it should be rejected. As it stands it can lead to confusing results like a binary with an embedded git sha1 the doesn’t actually match that of the ref it was built from. The current behavior seems very brittle.

[tnarg]

If I prefix the keys with STABLE_ can I access them from ctx.info_file?

[ashi009]

The behavior is well documented. I don't see a problem with the current design.

More over, the existence of volatile status provides an interface for bazel actions to access non-critical workspace status.