nx release version repeats logs

[mpsanchis]

Current Behavior

Small description here, a more detailed study in a comment below.

In many cases we see repeated lines in logs. An example is:

1. lib1 🏷️  Resolved the current version as 0.0.0 from git tag "libs@0.0.0", based on releaseTagPattern "libs@{version}"
2. lib1 ❓ Applied semver relative bump "patch", because a dependency project belonging to another release group was bumped, to get new version 0.0.1
3. lib1 ✍️  New version 0.0.1 written to manifest: dist/libs/lib1/package.json
4. lib1 🚫 No changes were detected using git history and the conventional commits standard
5. lib1 ❓ Applied semver relative bump "patch", because a dependency project belonging to another release group was bumped, to get new version 0.0.1
6. lib1 ✍️  New version 0.0.1 written to manifest: dist/libs/lib1/package.json
7. lib1 ✍️  Updated 1 dependency in manifest: dist/libs/lib1/package.json

Note how lines 2 & 3 are identical to 5 & 6.

This is not a big issue per se, but it is an indicator of more important problems in the algorithm.

Expected Behavior

Logs are not repeated

GitHub Repo

https://github.com/mpsanchis/nx-21-release

Steps to Reproduce

1. Clone repo in https://github.com/mpsanchis/nx-21-release
2. git checkout only-commons-syncd
3. npm i
4. npx nx release version

Note that the repository has several branches with different scenarios. This one corresponds to the following sketch:

Nx Report

NX   Report complete - copy this into the issue template

Node           : 18.20.8
OS             : darwin-arm64
Native Target  : aarch64-macos
npm            : 10.8.2

nx             : 21.2.0-beta.3
@nx/js         : 21.2.0-beta.3
@nx/workspace  : 21.2.0-beta.3
@nx/devkit     : 21.2.0-beta.3
---------------------------------------
Cache Usage: 0.00 B / 92.64 GB

Failure Logs

Package Manager Version

npm 10.8.2

Operating System

• macOS
• Linux
• Windows
• Other (Please specify)

Additional Information

Opening issue in case it helps you guys to track. An MR with failing tests will follow.

[mpsanchis]

Failing PR with tests that show this behaviour: #31722

[mpsanchis]

More details about the issue here:

The reason why some logs get written twice in projects which have dependencies is because of the double pass:

• (i.) propagateChanges(toGroup, fromGroup), when processing fromGroup
• (ii.) processGroup(toGroup), when processing toGroup

In the case of three-groups (branch here) :

apps ({ "projectsRelationship": "fixed" }):
- app1
  -> depends on lib1
- app2
libs ({ "projectsRelationship": "fixed" }):
- lib1
  -> depends on commons1
commons ({ "projectsRelationship": "fixed" }):
- commons1
- commons2

(i.) During processing of commons, the call chain is:

processGroup(commons)
├── bumpVersions(commons)
|   └── bumpFixedVersionGroup(commons) - (...)
└── propagateChangesToDependentGroups(commons)
    └── propagateChanges(libs, commons)
        └── bumpVersionForProject(lib1, patch, 'DEPENDENCY_ACROSS_GROUPS_WAS_BUMPED', {}) // fill log buffer, update project, update upstream deps
            ├── calculateNewVersion(lib1, 'patch', 'DEPENDENCY_ACROSS_GROUPS_WAS_BUMPED', {})
            └── versionActions.updateProjectVersion // (lib 1)

After processing commons, due to the change propagation, lib1 already has in its log:

lib1 🏷️ Resolved the current version as 0.0.0 from git tag "libs@0.0.0", based on releaseTagPattern "libs@{version}
lib1 ❓ Applied semver relative bump "patch", because a dependency project belonging to another release group was bumped, to get new version 0.0.1  
lib1 ✍️ New version 0.0.1 written to manifest: dist/libs/lib1/package.json  

(ii.) Then when processing libs, the call chain is:

processGroup(libs)
├── bumpVersions(libs)
|   └── bumpFixedVersionGroup(libs)
|       ├── determineVersionBumpForProject(libs, lib1) // only fill log buffer
|       ├── getFixedReleaseGroupBumpType(commons)
|       |   └── determineVersionBumpForProject(commons, commons1) // only fill log buffer - never flushed
|       ├── bumpVersionForProject(lib1, patch, 'DEPENDENCY_ACROSS_GROUPS_WAS_BUMPED', {})
|       └── updateDependenciesForProject(lib1)
|
└── propagateChangesToDependentGroups(apps)
    └── ...

First, determineVersionBumpForProject(libs, lib1) (for direct bumps), adds the following:

🚫 No changes were detected using git history and the conventional commits standard  

Then, bumpVersionForProject(lib1, patch, 'DEPENDENCY_ACROSS_GROUPS_WAS_BUMPED', {})) (for indirect bumps), adds the following:

lib1 ❓ Applied semver relative bump "patch", because a dependency project belonging to another release group was bumped, to get new version 0.0.1  
lib1 ✍️ New version 0.0.1 written to manifest: dist/libs/lib1/package.json  

Lastly, updateDependenciesForProject(lib1) adds:

lib1 ✍️  Updated 1 dependency in manifest: dist/libs/lib1/package.json

[JamesHenry]

@mpsanchis and I are discussing this, assigned myself