Overview

7 days30 days

Latest CI Pipeline Executions

Fuzzy

Succeeded
36257
a87458b1 fix(core): make nested integer-like spread errors base-independent The nested IntegerLikeSpreadKeyError only fired when the merge actually reached `mergeObjectWithSpread`. But a pre-`'...'` key the base owns takes the `result[key] = mergeBase[key]` shortcut in `mergeTargetConfigurations` (and the analogous `mergeConfigurations` config-name shortcut), dropping the incoming value without inspection — so a nested `{ '...': …, '<integer>': … }` never reached the throw. With a staging base the authored target threw IntegerLikeSpreadKeyError; when the real base owned the key it did not, so the staging error was discarded and the invalid object silently dropped. Mirror the top-level fix: extract the check into `assertNoIntegerLikeSpreadKey` and run it eagerly at both base-owns-key shortcuts before the incoming value is dropped, so the ambiguity throws regardless of which side owns the key. Also correct the staging comments in `project-configuration-utils.ts`: the discard is safe because throw reachability (not just the condition) is now base-independent, and name refs are skipped because `applySubstitutions` sweeps only the manager's rootMap.
by Craigory C...
Failed
36257
Flaky task→
a87458b1 fix(core): make nested integer-like spread errors base-independent The nested IntegerLikeSpreadKeyError only fired when the merge actually reached `mergeObjectWithSpread`. But a pre-`'...'` key the base owns takes the `result[key] = mergeBase[key]` shortcut in `mergeTargetConfigurations` (and the analogous `mergeConfigurations` config-name shortcut), dropping the incoming value without inspection — so a nested `{ '...': …, '<integer>': … }` never reached the throw. With a staging base the authored target threw IntegerLikeSpreadKeyError; when the real base owned the key it did not, so the staging error was discarded and the invalid object silently dropped. Mirror the top-level fix: extract the check into `assertNoIntegerLikeSpreadKey` and run it eagerly at both base-owns-key shortcuts before the incoming value is dropped, so the ambiguity throws regardless of which side owns the key. Also correct the staging comments in `project-configuration-utils.ts`: the discard is safe because throw reachability (not just the condition) is now base-independent, and name refs are skipped because `applySubstitutions` sweeps only the manager's rootMap.
by Craigory C...
Succeeded
36257
7ec54dbf cleanup(core): remove stale intermediate-rootmap docs and vestigial parameters [Self-Healing CI Rerun]
by nx-cloud[bot]
Failed
36257
Flaky task→
7ec54dbf cleanup(core): remove stale intermediate-rootmap docs and vestigial parameters [Self-Healing CI Rerun]
by nx-cloud[bot]
Succeeded
36257
1ecec970 chore(repo): retry ci [monitor-ci]
by Craigory C...
Failed
36257
Flaky task→
2e3d934e cleanup(core): remove stale intermediate-rootmap docs and vestigial parameters The default-plugin intermediate rootMap is now a throwaway synthesis feed, but several docs still described the deleted two-phase architecture: registerNameRefs told maintainers to pass an intermediate rootMap and call again later (re-introducing the sentinel-orphaning bug the staging comment warns about), the batch-merge wrapper JSDoc mentioned merging into other rootMaps, a spec comment described default batches merging outside the manager, and the public TargetDefaultFilter.plugin JSDoc predated the narrowed matching semantics (default-layer identities resolve to no source plugin). Also drops the rootMap override parameters every caller passed identically.
by Craigory C...
Failed
36257
2e3d934e cleanup(core): remove stale intermediate-rootmap docs and vestigial parameters The default-plugin intermediate rootMap is now a throwaway synthesis feed, but several docs still described the deleted two-phase architecture: registerNameRefs told maintainers to pass an intermediate rootMap and call again later (re-introducing the sentinel-orphaning bug the staging comment warns about), the batch-merge wrapper JSDoc mentioned merging into other rootMaps, a spec comment described default batches merging outside the manager, and the public TargetDefaultFilter.plugin JSDoc predated the narrowed matching semantics (default-layer identities resolve to no source plugin). Also drops the rootMap override parameters every caller passed identically.
by Craigory C...
Succeeded
36257
f96c833b fix(core): merge default plugins through the source-map-aware merge path Default plugin results (project.json, package.json, ...) were applied to the merged rootMap without source maps and their attribution grafted on afterwards with only-fill-missing semantics, so a field a default plugin overrode on an inferred target kept the inferring plugin's attribution (e.g. a project.json dependsOn shown as authored by @nx/gradle from build.gradle.kts). - default plugins now merge into the manager through the same source-map-aware merge as specified plugins and target defaults, so the merge itself decides field provenance for all three layers; the overlay and its heuristics are deleted - the intermediate staging merge only feeds target-default synthesis now: it is skipped when nx.json has no targetDefaults, writes no source maps, collects external nodes and merge errors into scratch objects (the real merge reports both), and no longer registers name-reference sentinels - filter.plugin attribution no longer needs staging source maps: a default plugin can never be named by the filter, so when the merged default layer authors a target's executor/command the target has no matchable source plugin; otherwise the specified layer's source maps name the originator
by Craigory C...
Failed
36257
Flaky task→
f96c833b fix(core): merge default plugins through the source-map-aware merge path Default plugin results (project.json, package.json, ...) were applied to the merged rootMap without source maps and their attribution grafted on afterwards with only-fill-missing semantics, so a field a default plugin overrode on an inferred target kept the inferring plugin's attribution (e.g. a project.json dependsOn shown as authored by @nx/gradle from build.gradle.kts). - default plugins now merge into the manager through the same source-map-aware merge as specified plugins and target defaults, so the merge itself decides field provenance for all three layers; the overlay and its heuristics are deleted - the intermediate staging merge only feeds target-default synthesis now: it is skipped when nx.json has no targetDefaults, writes no source maps, collects external nodes and merge errors into scratch objects (the real merge reports both), and no longer registers name-reference sentinels - filter.plugin attribution no longer needs staging source maps: a default plugin can never be named by the filter, so when the merged default layer authors a target's executor/command the target has no matchable source plugin; otherwise the specified layer's source maps name the originator
by Craigory C...