fix(release): add null-safe fallback for version in createGitTagValues#34598
Merged
fix(release): add null-safe fallback for version in createGitTagValues#34598
Conversation
When preferDockerVersion is true but dockerVersion is null (e.g. for
non-docker projects in a group with docker projects), the interpolate()
function receives null for {version} and returns the literal placeholder
string "{version}" in git tags instead of the actual version number.
Apply the same null-safe pattern already used in changelog.ts: fall back
to newVersion when dockerVersion is null (and vice versa), and skip tag
creation entirely when both are null.
Fixes #34382
Fixes #33890
Fixes #34391
When auto-enabling preferDockerVersion, distinguish between groups where
ALL projects have docker config vs only SOME. Mixed groups now use
'both' mode which already has proper null-safe checks for each version
type, preventing literal {version} tags for non-docker projects.
Add five test cases covering: - preferDockerVersion=true with null dockerVersion (fixed group) - preferDockerVersion=true with null dockerVersion (independent group) - Both versions null with preferDockerVersion=true - preferDockerVersion=false with null newVersion - Mixed independent group with some docker and some non-docker projects
✅ Deploy Preview for nx-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview for nx-dev ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Contributor
|
View your CI Pipeline Execution ↗ for commit 791b585
☁️ Nx Cloud last updated this comment at |
jaysoo
approved these changes
Feb 25, 2026
FrozenPandaz
pushed a commit
that referenced
this pull request
Feb 26, 2026
#34598) ## Current Behavior When nx release runs with docker-configured projects (either via explicit config or @nx/docker plugin inference), git tags are created with the literal string {version} instead of the actual version number (e.g., v{version} instead of v1.0.6, or app-3@{version} instead of [email protected]). This happens because: 1. If ANY project in a release group has docker config, preferDockerVersion is auto-set to true for the ENTIRE group 2. createGitTagValues() then blindly selects projectVersionData.dockerVersion, which is null for non-docker projects (or projects with no changes) 3. The interpolate() function receives null for {version} and returns the literal placeholder unchanged Commit messages are unaffected because createCommitMessageValues() only uses newVersion and already guards against null. The changelog code (changelog.ts:1117-1121) also already has the correct null-safe pattern. ## Expected Behavior When preferDockerVersion is true but dockerVersion is null, git tags should fall back to using newVersion instead of producing literal {version} placeholders. When both versions are null, no tag should be created. For mixed release groups (some projects have docker config, some don't), the auto-enable logic should use 'both' mode instead of true, which already has proper null-safe checks for each version type. ## Changes - shared.ts: Added null-safe fallback (??) in createGitTagValues() for both independent and fixed group code paths, plus a guard to skip tag creation when both versions are null - config.ts: Refined auto-enable logic to check whether ALL or only SOME projects have docker config — mixed groups now get 'both' mode instead of true - shared.spec.ts: Added 5 test cases covering null version fallback scenarios for fixed groups, independent groups, both-null, reverse fallback, and mixed groups ## Related Issue(s) Fixes #34382 Fixes #33890 Fixes #34391 (cherry picked from commit df9eb0b)
FrozenPandaz
pushed a commit
that referenced
this pull request
Feb 26, 2026
#34598) ## Current Behavior When nx release runs with docker-configured projects (either via explicit config or @nx/docker plugin inference), git tags are created with the literal string {version} instead of the actual version number (e.g., v{version} instead of v1.0.6, or app-3@{version} instead of [email protected]). This happens because: 1. If ANY project in a release group has docker config, preferDockerVersion is auto-set to true for the ENTIRE group 2. createGitTagValues() then blindly selects projectVersionData.dockerVersion, which is null for non-docker projects (or projects with no changes) 3. The interpolate() function receives null for {version} and returns the literal placeholder unchanged Commit messages are unaffected because createCommitMessageValues() only uses newVersion and already guards against null. The changelog code (changelog.ts:1117-1121) also already has the correct null-safe pattern. ## Expected Behavior When preferDockerVersion is true but dockerVersion is null, git tags should fall back to using newVersion instead of producing literal {version} placeholders. When both versions are null, no tag should be created. For mixed release groups (some projects have docker config, some don't), the auto-enable logic should use 'both' mode instead of true, which already has proper null-safe checks for each version type. ## Changes - shared.ts: Added null-safe fallback (??) in createGitTagValues() for both independent and fixed group code paths, plus a guard to skip tag creation when both versions are null - config.ts: Refined auto-enable logic to check whether ALL or only SOME projects have docker config — mixed groups now get 'both' mode instead of true - shared.spec.ts: Added 5 test cases covering null version fallback scenarios for fixed groups, independent groups, both-null, reverse fallback, and mixed groups ## Related Issue(s) Fixes #34382 Fixes #33890 Fixes #34391 (cherry picked from commit df9eb0b)
Contributor
|
This pull request has already been merged/closed. If you experience issues related to these changes, please open a new issue referencing this pull request. |
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
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.
Current Behavior
When nx release runs with docker-configured projects (either via explicit config or
@nx/docker plugin inference), git tags are created with the literal string {version}
instead of the actual version number (e.g., v{version} instead of v1.0.6, or
app-3@{version} instead of [email protected]).
This happens because:
true for the ENTIRE group
null for non-docker projects (or projects with no changes)
placeholder unchanged
Commit messages are unaffected because createCommitMessageValues() only uses newVersion and
already guards against null. The changelog code (changelog.ts:1117-1121) also already has
the correct null-safe pattern.
Expected Behavior
When preferDockerVersion is true but dockerVersion is null, git tags should fall back to
using newVersion instead of producing literal {version} placeholders. When both versions
are null, no tag should be created.
For mixed release groups (some projects have docker config, some don't), the auto-enable
logic should use 'both' mode instead of true, which already has proper null-safe checks for
each version type.
Changes
fixed group code paths, plus a guard to skip tag creation when both versions are null
docker config — mixed groups now get 'both' mode instead of true
groups, independent groups, both-null, reverse fallback, and mixed groups
Related Issue(s)
Fixes #34382
Fixes #33890
Fixes #34391