refactor(deployment): update SDK publishing workflow to align with dotCMS release strategy

[KevinDavilaDotCMS]

This PR introduces the changes to align the SDK release with the dotCMS release process

Already have the same code in core-workflow-test and the tests passed

dotCMS#514
dotCMS#516

This PR fixes: #36587

This PR fixes: #36587

[claude]

Claude finished @KevinDavilaDotCMS's task in 6m 18s —— View job

---

Claude Code Review

Re-reviewed origin/main...HEAD. The three prior findings are all resolved and the reviewer concerns (cancel-in-progress) are already addressed in the current code. One non-blocking robustness note on the new idempotency guard.

New Issues

• 🟡 Medium: .github/actions/core-cicd/deployment/deploy-javascript-sdk/action.yml:172 — the idempotency guard if npm view "@dotcms/${sdk}@${RELEASE_VERSION}" version >/dev/null 2>&1; then ... skip relies on npm view exit code to decide "already published". npm view on a scoped package returns a non-zero E404 only when the version is missing on some npm versions, but on others it prints nothing and exits 0 for a not-yet-published version of an existing package. If the latter behavior applies to the runner's npm, every already-existing package (i.e. all of them after the first release) would be misdetected as "already published" and silently skipped, so a real release would publish nothing while reporting success.
  • Assumption: the loop's correctness depends on npm view <scoped>@<missing-version> exiting non-zero.
  • What to verify: run npm view "@dotcms/client@99.99.99-nope" version; echo $? on the pinned Node/npm (core-web/.nvmrc). If it exits 0, gate on non-empty output instead of exit code, e.g. if [ -n "$(npm view "@dotcms/${sdk}@${RELEASE_VERSION}" version 2>/dev/null)" ]; then. That form is correct regardless of npm version. Fix this →

Resolved

• ✅ .github/workflows/cicd_release-sdk.yml:121 — notify-precheck-failure now checks out (actions/checkout@v4) before referencing the local notify-slack action; the Slack notice is no longer a silent no-op.
• ✅ .github/workflows/cicd_release-sdk.yml:88-94 — IS_LTS is now derived from RELEASE_VERSION on workflow_dispatch (and TAG_NAME on release), so an LTS-shaped manual dispatch is correctly skipped instead of publishing.
• ✅ .github/actions/core-cicd/deployment/deploy-javascript-sdk/action.yml:172 — publish loop is now re-runnable: an already-published version is treated as success, so a resumed run can finish the remaining packages (modulo the exit-code caveat above).
• ✅ .github/workflows/cicd_release-sdk.yml:42-50 — cancel-in-progress: false matches cicd_6-release.yml, addressing @dcolina's half-published concern.

Notes (non-blocking)

• Removals are consistent: publish-npm-sdk-libs was dropped from both the caller (cicd_3-trunk.yml) and the definition (cicd_comp_deployment-phase.yml), and set to false in cicd_6-release.yml — no dangling reference. The deleted core-web/libs/sdk/VERSION has no remaining references. The sdk_libs filter in .github/filters.yaml is still used for PR area-labeling, so keeping it is correct.
• @sfreudenthaler's question (why keep the deprecated cicd_manual-release-sdks.yml rather than delete): the file's own header answers it — kept disabled as a clean revert path per ADR-0019's "confirm before deleting" guidance. That's an author decision, not a code issue.

• 36587-align-sdk-publish-pipeline-with-dotcms-date-lockstep-versioning

[KevinDavilaDotCMS]

Went through all 3 findings from the Claude code review against the actual code at this commit — unlike the earlier deepseek-bot round on the fork PR, these were all real and confirmed by direct inspection. Fixed all three.

Fixed

• Missing checkout in notify-precheck-failure (🟠 High) — confirmed real, and on us: we added actions/checkout to the publish job when fork testing caught this exact issue there, but never propagated the same fix to notify-precheck-failure (added earlier, in the previous review round, to make a pre-check failure non-silent). It went untested because our fork tests never exercised a precheck failure path (only success, LTS-skip, and dry-run). Added the missing checkout step — same reasoning as the publish job's comment: a local (./) action can't be resolved on an empty runner workspace, so the Slack notification was a silent no-op.
• IS_LTS never computed for workflow_dispatch (🟡 Medium) — confirmed real. The regex validating manual-dispatch versions explicitly allows the _lts_v## shape, but IS_LTS was only ever derived inside the release-event branch, defaulting to false for manual runs. A manual dispatch with an LTS-shaped version would pass validation and then actually publish, contradicting the documented skip-LTS policy. Fixed by deriving IS_LTS from whichever value carries the marker for that event type (tag_name for release, RELEASE_VERSION for workflow_dispatch) instead of only the former.
• Publish loop not retriable on partial failure (🟡 Medium) — confirmed real, and a legitimate operational trap under the new model: the version is fixed to the dotCMS release tag and can never be bumped (unlike the old @next scheme, which side-stepped this with a fresh run-number suffix each retry). If package N of 10 failed mid-loop, packages 1..N-1 were already published immutably, and a re-run would hit npm's hard rejection on republishing an existing version — permanently stalling that release's SDK publish with no clean recovery. Made the loop idempotent: each package now checks npm view @dotcms/$sdk@$RELEASE_VERSION first and treats an already-published version as success, so a re-run (or a run resumed after cancel-in-progress killed a prior one) can finish whatever's left.

Same changes mirrored into the core-workflow-test fork branches, ready to be re-verified there before this goes back for another look.

[sfreudenthaler]

A few considerations and open questions, but no blocking commentary.

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request