Repository navigation
Watch host_key.py so a module upgrade reaches existing output bases - #6
Merged
Merged
Conversation
The rule runs host_key.py through rctx.path, which Bazel does not record. An upgrade that changed only the script, with defs.bzl and the rule's attributes unchanged, left an existing output base on the old script's key and watches until some other watched path changed. 0.0.3 was such an upgrade: its watches through links reached a fresh output base but not one that had run 0.0.2. The real-Bazel check now runs a scratch copy of the module, replaces its host_key.py in a running server, and expects the action to run again; without the watch that step reuses the old result.
Carries the rule's watch on its own host_key.py, so upgrading to this release re-runs the rule in every output base, and a later upgrade that changes only the script reaches existing output bases too.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The rule runs
host_key.pythroughrctx.path(Label("//:host_key.py")), andBazel 9.2.0 records nothing for a file reached that way. So an upgrade that
changes only the script, with
defs.bzland the rule's attributes unchanged,leaves the rule key and every recorded input equal: an existing output base
keeps the old script's key and watches until some other watched path changes.
0.0.3 was such an upgrade. In a consumer's output base that had run 0.0.2 (with
the #2 and #3 changes applied as patches), fetching 0.0.3 left the repository's
marker as 0.0.2 wrote it, without #4's
/var/db/xcode_select_link/usr/bin/xcodebuildwatch. A fresh output baserecorded that watch. Both computed the same key,
d2cf2921....Change
defs.bzlwatches//:host_key.pybefore running it.tests/check_platform.pyruns a scratch copy of the module, so a new laststep can replace the copy's
host_key.pyin a running server with one thatreports another key, and expect the action to run again.
output base.
MODULE.bazeland the README snippet.The key's digest input is unchanged. Because
defs.bzlchanges, upgrading to0.0.4 re-runs the rule once in every output base, which computes the same key.
Verification
tests/check_platform.pypasses on macOS 26.7 with Bazel 9.2.0; the host keystays
d2cf2921.... Run against a copy of the module without the watch, itfails at the new step:
host_key.py upgraded, running server: expected executed, got reused.