Repository navigation
refactor(project): Correct resource tag lifecycle and build scope - #1679
Merged
Merged
Conversation
Cached tag operations can remain pending when a project finishes. A later read then replays its build tags. Output filtering can also leave a monitor referencing the build tag store after the store is cleared. Apply pending operations before clearing both the build store and its monitor. Keep project tags available to dependents and retain both result-stage monitor resets so resource snapshots expose final tags. Reset all stores and monitors when initializing stages for another build. Keep build tags separate from build-manifest storage. Sharing that object with project tags allows build tags to alter manifest contents. Add regressions for live and cached completion, output filtering, repeated builds, final tag snapshots, and manifest isolation.
A step that reruns after a dependency changes can update a tag, then have its value overwritten when recordStageResult imports the previous stage's operations. Later stages see stale values even though the cache stores the correctly merged operations. Import the merged project and build tag operations into the live collections. Current delta values take precedence, while tags unchanged by the delta remain available to subsequent stages. Extend the cache tests to check the values imported for later stages as well as the values written to the persistent cache.
RandomByte
force-pushed
the
refactor/build-tag-isolation
branch
from
October 26, 2026 14:36
5a917e9 to
22bc968
Compare
Tasks can tag dependency resources during a build. Routing all tags to the resource owner exposes build tags to other projects and records tag operations against the wrong project's stage cache. Route build tags through the executing project's ProjectResources, matching the v4 build-context scope. Continue to store project tags on the resource owner. Classify tags without replaying cached operations or creating a monitor that would capture a stage snapshot too early. Cover cold, warm-cache, and delta builds with legacy and step-based tasks, plus serving restarts and rebuilds. Verify dependency isolation, project-tag visibility, and output filtering.
RandomByte
force-pushed
the
refactor/build-tag-isolation
branch
from
October 26, 2026 14:48
22bc968 to
4fece12
Compare
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.
Resource tags can behave differently across cold, cached, and incremental builds. These changes address three causes:
Clear build tags when a project finishes. Pending cached operations can restore build tags after completion, and a monitor can retain the cleared store. Apply pending operations before clearing both the build tag store and its monitor. Reset all stores and monitors when initializing another build, and keep build tags separate from build-manifest storage. Project tags remain available to dependents.
useResultStage()continues to reset both monitors so resource snapshots expose the final tags.Preserve current tag values during delta replay. After a step updates a tag,
recordStageResult()can overwrite it by importing the previous stage's operations. Import the merged operations already used for cache persistence. Later stages then see current values while retaining tags unchanged by the delta.Scope build tags to the executing project. Routing build tags to a dependency resource's owner makes them visible to other projects and records operations against the wrong project's stage cache. Restore the v4 scope: build tags belong to the executing project, including tags on dependency resources. Project tags continue to belong to the resource owner. Tag classification avoids cached replay and monitor creation.
Regression coverage includes cold builds, persistent cache restores, dependency and consumer changes, output filtering, and serving restarts and rebuilds. Both legacy and step-based tasks are covered.