Repository navigation
feat(dirty-set): stay incremental across package boundary changes - #24
Conversation
Adding or removing a package only changes the hashes of its own targets, the targets of its nearest enclosing package (whose globs gain or lose the directory's files), and their reverse deps. Route both cases through the existing dirty-package machinery instead of a full rehash: added packages are re-listed by wildcard, removed packages have their labels dropped, and the nearest enclosing package on both sides is dirtied. Whether a deleted BUILD file's package survives is resolved from the diff when possible, otherwise with a single batched git ls-tree. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Rename siblingBuildFile to otherBuildFile and ambiguousDeletions to deletionsNeedingLookup, and spell out at the call site why the other BUILD file name decides whether the package is removed. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…heir own code ComputeDirtySet now reads as its steps: fallback triggers, seed package index, boundary changes, dirty packages, rdeps propagation (reusing propagateFrom). A failing package existence lookup reports package_lookup_error instead of package_boundary_change, so the latter no longer means two different things. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…package deletions Also drop BUILD-file boundaries from the README's fallback triggers, and explain why source files are attributed using the seed's packages. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
| // findDirtyPackages returns every package whose targets must be rehashed: | ||
| // packages of changed files, the added and removed packages themselves, and | ||
| // the nearest enclosing package of each. The result includes removed | ||
| // packages, whose seed labels must be invalidated. |
There was a problem hiding this comment.
I asked Codex to help me review the PR because I find the hypotheticals and possible conditions we are getting into at this point make my head hurt, and it had one thing to flag here - but I think the risk is acceptable:
indexSeedPackagesonly knows packages that appear in target hashes or dependency edges. When a BUILD file is added or removed, the nearest enclosing package may already exist but have no labels in that seed graph—for example, its rules produced no matching targets at the seed revision.In that case,
findDirtyPackagescan miss the enclosing package. Its unchanged BUILD file may produce a different target set becauseglob()orsubpackages()sees the new package boundary, but the scoped query never re-lists it. A removed child package with no seed labels can even take the “no targets affected” path and copy the seed output
IIUC the risk would be that a package exists but has no targets/labels, meaning it only defines something like a filegroup based on a glob - which seems rare
2 participants
Summary
Seeded runs no longer fall back to a full rehash (
package_boundary_change) when a BUILD file is added or deleted.Adding or removing a package at directory D only changes the hashes of targets in D, targets in the nearest enclosing package (its globs and
subpackages()gain or lose D's files), and their reverse deps. Packages further up can't see past the enclosing package. Both cases now reuse the existing dirty-package machinery (wildcard re-list, probe pruning, rdeps propagation)://P:all; the nearest enclosing package is dirtied as if its BUILD file changed.DirtySetResult.RemovedPackages. Its seed labels are dirtied (dropped from the merge, rdeps propagated), but it never gets a wildcard or a probe, and its labels are never carried explicitly. The package absorbing its files is dirtied.git ls-treeper run. If the lookup fails, the run falls back with a new code,package_lookup_error, sopackage_boundary_changeis no longer emitted.R*status branch:gitDiffNameStatususes--no-renames..bzl, module and other fallback triggers are unchanged.Test plan
git ls-treeagainst a temp repohash-differ, all runs incremental with no fallback🤖 Generated with Claude Code