fix(docker): enhance docker project filtering and configuration handling

[AndriiTsok]

Current Behavior

When a release group has docker configuration, all projects in that group inherit the docker options, regardless of whether they are actually docker projects. This causes issues when you have mixed release groups containing both npm packages and docker-based applications.

For example, if you have a release group with:

• Docker applications (with @nx/docker:release-publish executor)
• Regular npm packages

Currently, the npm packages would incorrectly receive docker configuration and potentially be processed during docker operations, even though they don't have docker capabilities.

Additionally, a regression was observed where projects without any version changes were still being processed for docker publishing, causing tag failures. #33276

Expected Behavior

With this PR, docker options are only applied to projects that meet one of these conditions:

1. The project has explicit project-level docker configuration, OR
2. The project has the nx-release-publish target with the @nx/docker:release-publish executor

This ensures that:

• Only actual docker projects get docker configuration
• Docker processing skips projects without docker targets
• Docker processing skips projects with no version changes (preventing tag failures)
• Mixed release groups (npm + docker) work correctly

The fix includes proper filtering in both the release graph construction and the docker processing pipeline, with test coverage for the described scenarios.

Related Issue(s)

Fixes #33276

[netlify]

👷 Deploy request for nx-docs pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	4f988b2

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Updated (UTC)
nx-dev	Ready	Preview	Oct 29, 2025 4:38am

[AndriiTsok]

Hello @emiliosheinz and @Coly010 I just wanted to reach out to you to ask if you were experiencing issues with the new {versionActionsVersion} #33178

I started using it and I noticed, that for independently released projects it does not work well.

Projects that are not affected by new version are trying to be published by the docker plugin, and also non-docker plugins get to inherit dockerOptions field during the release pipeline business logic.

I assume this issue was not obvious as before {versionActionsVersion} the plugin would just get date and commit has - and would never fail to get a new version.

I think PR I made two changes:

https://github.com/nrwl/nx/pull/33288/files#diff-0592620b916195adeff99ea1151ecca4658d17269242f5a747fb77ccb4526c13R823

https://github.com/nrwl/nx/pull/33288/files#diff-6a6abc890ab87dd0da1d18eeed93c2c28591f6bbc9a7ffddee082704df2caaf4R269-R290

That should correct the way we choosing projects for docker release/publish process.

I would appreciate your feedback as I see you both are using the new plugin. Thank you!

[emiliosheinz]

Hey @AndriiTsok thank you for reporting, I'll take a look once I get the chance.

[emiliosheinz]

Won't this break the current behavior for projects that have skipVersionActions set to true?

[emiliosheinz]

Hey @AndriiTsok, I'm quite new to the codebase, and the addition of {versionActionsVersion} was my first contribution. I took a look at your code and the related issues, and from my perspective, I don't quite understand the relation between what you are describing with the newly introduced version scheme. I'll let @Coly010 take a look and share his thoughts.

BTW, this is the config I'm planning to apply to my monorepo. From what I have tested so far, it works well.

[emiliosheinz]

@AndriiTsok I ended up facing the same issue in my monorepo. What I did:

• Partially replaced Nx with Turborepo. See: feat: replace nx with turborepo for better dx and improve release pipelines emiliosheinz/loci#54
• Kept Nx only for tagging, releasing, and generating changelogs. See: https://github.com/emiliosheinz/loci/blob/main/nx.json
• npm packages and Docker images publishing is done through a separate workflow that is triggered every time a new tag is created, so I have complete control over it. See: https://github.com/emiliosheinz/loci/blob/main/.github/workflows/on-tag-publish.yml. I'm working on some small performance improvements, mostly related to multi-arch images build, but this should do the trick.

So far, I'm happy with the results. I hope it helps to unblock you. And please, let me know if you have any questions.

[AndriiTsok]

Hi @emiliosheinz, thank you for your feedback! Yes, this is the issue, it is happening when you have more than 1 project in a group/default group and only a few of them are being affected and released.

This PR addresses the issue and fixes multiple regression issues that happened during the recent developments in @nx/docker

Hopefully @Coly010 or @leosvelperez can take a look at this soon. Because as of now, the docker release flow got broken for multi app projects.

As a workaround, for releases, for now, I just triggering global change that affects all projects to bump the version for all apps.