Skip to content

[pull] main from bazel-contrib:main - #747

Merged
pull[bot] merged 1 commit into
garymm:mainfrom
bazel-contrib:main
Sep 17, 2026
Merged

pull[bot] merged 1 commit into
garymm:mainfrom
bazel-contrib:main

Conversation

@pull

@pull pull Bot commented Sep 17, 2026 •

Copy link
Copy Markdown

See Commits and Changes for more details.


Created by pull[bot] (v2.0.0-alpha.4)

Can you help keep this open source service alive? 💖 Please sponsor : )

## Summary

`PyWriteBuildData` is dirty on every build with a cold Skyframe when
outputs are not downloaded. That is, once per `py_binary` and `py_test`
in the build. When stamping is off, the output is a constant, so the
action spawn is pure overhead.

## Root Cause Analysis

The output is declared with
`_py_builtins.declare_constant_metadata_file`. Constant metadata always
reports itself as unchanged, so Bazel cannot validate it from the action
cache. It stats the output on disk instead.

Under `--remote_download_outputs=minimal` the output is not on disk. The
stat fails and the action is dirty. It re-executes, hits the remote
cache, is still not downloaded, and is dirty again on the next
cold-server build. Setting `--remote_download_regex` to match the file
avoids this, at the cost of downloading it, which confirms the stat is
the trigger.

The use of a constant metadata file is justified (as per the comment in
the code). With stamping on, the action reads `volatile-status.txt`,
which changes every build. The build data file is in the binary's
runfiles, so without it its consumers would invalidate on every build
due to timestamps.

However, with stamping off, there is no volatile input. There is nothing
to shield. Unfortunately, the current implementation keeps the
_additional_ cost (constant metadata being always unchanged plus failed
`stat` syscalls) for none of the benefits.

## Change

When `is_stamping_enabled(ctx)` is false, the content of the file is
known at analysis time:

```
TARGET <label>
STAMPED FALSE
```

So declare an ordinary output and write it with `ctx.actions.write`. No
spawn, and no constant metadata output.

Note this is broader than `--nostamp`. `is_stamping_enabled` is also
false for the exec configuration and for `stamp = 0`, so tool-config
binaries benefit from the fix even when `--stamp=true` is set at the top
level.

The stamped path is unchanged and keeps its constant metadata output.

## Compatibility

The output is byte-identical. The label is written with `str(ctx.label)`
to match `"TARGET": str(ctx.label)` in the spawn's env, which yields the
canonical `@@//pkg:target` form. `ctx.actions.args().add(ctx.label)`
renders the display form and drops the `@@`.

After the change, the tests in `tests/build_data/build_data_test.py`
pass without any modifications.

## Alternative considered

Keeping the spawn and declaring an ordinary output would also fix the
dirtiness. Writing at analysis time is lighter, since it needs no
subprocess.

## Environment

rules_python 2.2.0, Bazel 9.2.0, Linux. Reproduce with
`--remote_download_outputs=minimal` against a warm remote cache, then
`bazel shutdown` and rebuild.
@pull pull Bot locked and limited conversation to collaborators Sep 17, 2026
@pull pull Bot added the ⤵️ pull label Sep 17, 2026
@pull
pull Bot merged commit ff35ee4 into garymm:main Sep 17, 2026
3 checks passed
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant