Overview

7 days30 days

Latest CI Pipeline Executions

Fuzzy

In progress
36693
8ad3d438 fix(gradle): pass the task to a dependsOn closure, and test the path splitting Two defects found reviewing the branch. A Groovy `dependsOn { … }` stores a `groovy.lang.Closure`, which implements `GroovyCallable` and so is a `Callable`. It matched the Callable arm and was invoked with no argument, while Gradle calls it with the task — so any closure using its parameter threw, was swallowed, and lost its edge. Closures are now handled ahead of Callable and receive the task. Expanding `dependsOn` also invokes user closures, and several call sites per task need that expansion, so it is memoized rather than recomputed — previously a closure could run once per caller. `resolvePathDeps` had no effective coverage: both tests passed against an implementation returning nothing, one via a short-circuiting `||` and the other vacuously. Replacing its body with `emptyList()` left the whole suite green. The tests now build real child projects and assert the resolved pairs, and both new tests fail when their fix is reverted.
by FrozenPandaz
Succeeded
36693
03f6e79e chore(gradle): format mock files Co-authored-by: FrozenPandaz <FrozenPandaz@users.noreply.github.com>
by nx-cloud[bot]
Canceled
36693
baf82869 chore(gradle): format mock files Co-authored-by: FrozenPandaz <FrozenPandaz@users.noreply.github.com>
by nx-cloud[bot]
Canceled
36693
02deb1ee fix(gradle): attribute projects from the report's own build-file pairing Each per-project report already names one project and the one build file that configures it, but processNxProjectGraph flattened those into a Set and threw the pairing away, so nodes.ts rebuilt it by walking directories upward and guessing. The pairing is now carried through and used directly. That removes the guessing rather than refining it: the walk could not be right for a project whose directory ancestry and Gradle project ancestry differ (settings.gradle remapping a projectDir), and it matched a hardcoded pair of build file names, so a renamed build file never resolved. A project the report gives no build file for is skipped with a verbose log naming the likely cause, instead of vanishing silently — it is unreachable once `@nx/gradle:init` has run, since that writes a build file next to every settings.gradle. Also, from the same review pass: - A `dependsOn { … }` Callable is now expanded rather than dropped when the bypass fires. Gradle resolves it by calling it and so do we; the result is classified by the same rules, so nothing reaches Gradle's task resolver. - A task whose dependsOn holds a FileCollection or a raw TaskDependency is reported uncacheable when the bypass fires. Those only yield their tasks by resolving, which is what deadlocks, so the dependency set is knowably short — and a cache key built from a short dependency set is a stale hit waiting to happen. Not caching is the honest answer; recovering them properly needs a configuration-time phase, which is a larger change than this fix. - flattenDependsOn keeps an identity-based visited set. Gradle's own DefaultTaskDependency drains an ArrayDeque with no cycle guard, so a cyclic structure spins there; it cannot reach dependsOn literally (Gradle hashes values into a Set first, which overflows), but it can now arrive via a Callable's return. Adds a dependencies.spec.ts for the static/implicit predicate, which had no coverage, and Kotlin tests for the path forms, the cache gating, the Callable, and the cycle.
by FrozenPandaz
Failed
36693
Fix applied→
02deb1ee fix(gradle): attribute projects from the report's own build-file pairing Each per-project report already names one project and the one build file that configures it, but processNxProjectGraph flattened those into a Set and threw the pairing away, so nodes.ts rebuilt it by walking directories upward and guessing. The pairing is now carried through and used directly. That removes the guessing rather than refining it: the walk could not be right for a project whose directory ancestry and Gradle project ancestry differ (settings.gradle remapping a projectDir), and it matched a hardcoded pair of build file names, so a renamed build file never resolved. A project the report gives no build file for is skipped with a verbose log naming the likely cause, instead of vanishing silently — it is unreachable once `@nx/gradle:init` has run, since that writes a build file next to every settings.gradle. Also, from the same review pass: - A `dependsOn { … }` Callable is now expanded rather than dropped when the bypass fires. Gradle resolves it by calling it and so do we; the result is classified by the same rules, so nothing reaches Gradle's task resolver. - A task whose dependsOn holds a FileCollection or a raw TaskDependency is reported uncacheable when the bypass fires. Those only yield their tasks by resolving, which is what deadlocks, so the dependency set is knowably short — and a cache key built from a short dependency set is a stale hit waiting to happen. Not caching is the honest answer; recovering them properly needs a configuration-time phase, which is a larger change than this fix. - flattenDependsOn keeps an identity-based visited set. Gradle's own DefaultTaskDependency drains an ArrayDeque with no cycle guard, so a cyclic structure spins there; it cannot reach dependsOn literally (Gradle hashes values into a Set first, which overflows), but it can now arrive via a Callable's return. Adds a dependencies.spec.ts for the static/implicit predicate, which had no coverage, and Kotlin tests for the path forms, the cache gating, the Callable, and the cycle.
by FrozenPandaz
Succeeded
36693
baa747f8 fix(gradle): address review findings on node creation and the dependency bypass Critical: pluginCache collided across project roots. calculateHashesForCreateNodes hashes the files under a root, not the root itself, so two roots that own no files of their own hashed identically — a shape this PR introduced by driving off the report's project roots. The second root then read the first's config, which the checked-in plugin.spec.ts snapshot had pinned as expected: it recorded proj/application under the root project's name and targets. The cache key now includes the root, and the snapshot records proj/application as "application". Also: - Roots outside the workspace (an includeBuild("../x"), which the reporter leaves absolute by design) were attributed to the workspace-root build file instead of being rejected. - buildFileFor matched a hardcoded ['build.gradle', 'build.gradle.kts'], so a renamed build file reached allBuildFiles through the report but never matched. It is indexed by directory now. - One qualified path discarded every TaskDependency edge for that task, including same-project ones: `dependsOn("classes", ":other:jar")` lost `classes`, and every dependsOn(taskProvider) went with it. Those resolve inside the already-configured declaring project, so they are recovered locally. - NX_GRADLE_SKIP_TASK_DEPS suppressed the dependency walk without triggering the compensating input widening — the stale-cache hazard the widening exists to prevent. Both sites now share one predicate. - taskDependencyCache still keyed on task.path, which collides across included builds. Barely reachable at 5 projects; reachable at 71. - Documented NX_GRADLE_SKIP_TASK_DEPS, and covered resolvePathDeps' path forms and the nested-list dependsOn shape.
by FrozenPandaz
Failed
36693
Fix applied→
a912c778 fix(gradle): over-declare inputs for a recovered path dependsOn A qualified-path dependsOn is deliberately never resolved to a Task, so the dependency walk behind dependentTasksOutputFiles finds nothing and the task's inputs came out narrower than they should be — silently, and in the direction that yields a stale cache hit rather than a loud failure. Fail open to the catch-all instead, matching what declaresDirectoryOutput already does when it cannot read a task's output model. Over-declaring costs a rebuild; under-declaring costs a wrong answer. On apache/kafka, :streams:testAll goes from no dependentTasksOutputFiles entry at all to the catch-all.
by FrozenPandaz
Canceled
36693
72958714 fix(gradle): correct the dependency array type and the comments around it The dependencies array was still typed Array<StaticDependency> while the implicit branch pushes an ImplicitDependency, which does not compile. Comment fixes from review: - effectiveBuildFile was inserted between getNxProjectName's KDoc and its declaration, leaving that doc describing the wrong function. - pathStringDeps' doc claimed it returns absolute paths; it returns every string in dependsOn, and qualifiedPathDeps is what filters them. - Two comments said "absolute path" where the code tests for a qualified one.
by FrozenPandaz
Canceled
36693
c37261e2 chore(gradle): move the Groovy apply-plugin fix to its own PR The `apply plugin:` colon fix and its test changes are unrelated to the plugin changes here, so they now live in their own pull request. Net effect on this branch: the init generator is untouched.
by FrozenPandaz
Failed
36693
Fix ready→
c37261e2 chore(gradle): move the Groovy apply-plugin fix to its own PR The `apply plugin:` colon fix and its test changes are unrelated to the plugin changes here, so they now live in their own pull request. Net effect on this branch: the init generator is untouched.
by FrozenPandaz
Failed
36693
Fix ready→
6fc5018e fix(gradle): support builds that configure subprojects from an ancestor build file Three independent bugs, all surfaced by running @nx/gradle against apache/kafka. 1. The init generator emitted invalid Groovy. When a build file already had an `allprojects {}` block, it wrote `apply plugin "dev.nx.gradle.project-graph"` without the named-argument colon, so Groovy read `plugin` as a property and the build failed with "Could not get unknown property 'plugin'". The existing unit test asserted the broken output, so it went unnoticed. The idempotency check is updated to recognise both DSL forms, otherwise a second run appended a duplicate apply. 2. nxProjectReport deadlocked. It calls TaskDependency.getDependencies() from a task action; resolving a dependsOn declared as a task *path* sends Gradle through ensureProjectsConfigured, re-entering the configuration phase during execution and blocking forever on the build-lifecycle state lock. Builds that declare cross-project dependsOn by path hang until the plugin's timeout. Such tasks now skip that call and recover the edges by parsing the path — findProject() returns the project without configuring it. Both absolute (`:a:b:test`) and relative (`connect:api:jar`) forms are handled, and nested collections are flattened first because `dependsOn: [a, b]` stores the whole list as a single element. Bare names still go through TaskDependency, which keeps effectiveDependencyPatterns able to see through lifecycle tasks. 3. Projects without their own build file were dropped entirely. A project can be configured from an ancestor via `project(':core') { }`; Kafka configures ~40 subprojects this way and has only one build file in the whole repo. Four places assumed otherwise, so those projects reached the graph with no node, no dependsOn and no dependency edges. They are now attributed to the build file that configures them, and nodes are built from the report's project roots rather than from dirname(buildFile) — which would collapse every subproject onto the root. Nx rejects a static dependency whose sourceFile lives outside the source project, so edges attributed to an ancestor file are recorded as implicit. Also memoizes the task-dependency and output-pattern lookups, which effectiveDependencyPatterns otherwise recomputes once per task. On apache/kafka, `nx show projects` goes from 5 projects and 72 graph edges to 71 projects and 547 edges.
by FrozenPandaz
Failed
36693
Fix applied→
6fc5018e fix(gradle): support builds that configure subprojects from an ancestor build file Three independent bugs, all surfaced by running @nx/gradle against apache/kafka. 1. The init generator emitted invalid Groovy. When a build file already had an `allprojects {}` block, it wrote `apply plugin "dev.nx.gradle.project-graph"` without the named-argument colon, so Groovy read `plugin` as a property and the build failed with "Could not get unknown property 'plugin'". The existing unit test asserted the broken output, so it went unnoticed. The idempotency check is updated to recognise both DSL forms, otherwise a second run appended a duplicate apply. 2. nxProjectReport deadlocked. It calls TaskDependency.getDependencies() from a task action; resolving a dependsOn declared as a task *path* sends Gradle through ensureProjectsConfigured, re-entering the configuration phase during execution and blocking forever on the build-lifecycle state lock. Builds that declare cross-project dependsOn by path hang until the plugin's timeout. Such tasks now skip that call and recover the edges by parsing the path — findProject() returns the project without configuring it. Both absolute (`:a:b:test`) and relative (`connect:api:jar`) forms are handled, and nested collections are flattened first because `dependsOn: [a, b]` stores the whole list as a single element. Bare names still go through TaskDependency, which keeps effectiveDependencyPatterns able to see through lifecycle tasks. 3. Projects without their own build file were dropped entirely. A project can be configured from an ancestor via `project(':core') { }`; Kafka configures ~40 subprojects this way and has only one build file in the whole repo. Four places assumed otherwise, so those projects reached the graph with no node, no dependsOn and no dependency edges. They are now attributed to the build file that configures them, and nodes are built from the report's project roots rather than from dirname(buildFile) — which would collapse every subproject onto the root. Nx rejects a static dependency whose sourceFile lives outside the source project, so edges attributed to an ancestor file are recorded as implicit. Also memoizes the task-dependency and output-pattern lookups, which effectiveDependencyPatterns otherwise recomputes once per task. On apache/kafka, `nx show projects` goes from 5 projects and 72 graph edges to 71 projects and 547 edges.
by FrozenPandaz