bug(ci): release workflow overwrites :latest and relabels "Next Release" issues from any source branch

[erickgonzalez]

Problem Statement

When .github/workflows/cicd_6-release.yml is dispatched via workflow_dispatch
from a branch other than main (e.g. a release branch like 26.04.11, a hotfix
branch, or an experimental Java-variant branch), two side effects fire that
should be exclusive to main:

1. Docker :latest tag is overwritten. The image built from the non-main
   branch replaces :latest, even though main is the source of truth for what
   :latest should point to. Users pulling dotcms/dotcms:latest may receive
   an image that does not correspond to main.

2. GitHub issue labels are mis-applied. Issues currently labeled
   Next Release (set when fixes merge to main) get re-labeled with the
   dispatched release_version. A fix that landed on main and is awaiting
   the next release will be wrongly stamped with a release version that does
   not actually contain that fix.
   Concrete example: a fix is merged to main and carries the Next Release
   label. A maintenance release is dispatched from branch 26.04.11. The fix
   is not in 26.04.11, but the issue ends up labeled 26.04.11, making
   the GitHub release labels unreliable for downstream consumers.

Root cause

• is_latest in cicd_comp_release-prepare-phase.yml (lines 115–117) is
  computed purely from the version-string regex and never consults
  github.ref_name.
• update_github_labels in cicd_6-release.yml (line 153) is passed straight
  from the workflow input with no branch guard.

Steps to Reproduce

1. Open the GitHub Actions UI → select the -6 Release Process workflow.
2. In the "Use workflow from" dropdown, pick a branch other than main
   (e.g. a release branch like 26.04.11 or any hotfix branch).
3. Enter a standard release version (e.g. 26.04.11-01); leave
   update_github_labels checked (default).
4. Run the workflow.
5. Observe:
   • The Deployment job pushes the Docker image with the :latest tag
     (visible in the deploy-docker step logs and on Docker Hub).
   • The Release job relabels GitHub issues currently tagged Next Release
     to the dispatched release_version, even though those fixes are not in
     this branch.

Acceptance Criteria

• When the release workflow is dispatched from a branch other than main,
  Docker :latest is not updated.
• When the release workflow is dispatched from a branch other than main,
  GitHub issues are not relabeled (the update_github_labels step is
  skipped or evaluates false).
• When dispatched from main with a standard (non-LTS) version, :latest
  is still updated as today.
• When dispatched from main with update_github_labels = true,
  Next Release issues are still relabeled as today.
• Artifactory deploy, javadocs upload, plugin updates, SBOM, and the Slack
  notification continue to obey their existing workflow inputs and are
  not branch-gated (they are legitimate from a non-main release branch).

Suggested fix

Two two-line edits in .github/workflows/cicd_6-release.yml:

# Line 124
latest: ${{ needs.release-prepare.outputs.is_latest == 'true' && github.ref_name == 'main' }}

# Line 153
update_github_labels: ${{ github.event.inputs.update_github_labels == 'true' && github.ref_name == 'main' }}

dotCMS Version

CI/CD pipeline — current main branch (version-agnostic).

Severity

Medium - Some functionality impacted

Links

• Related: fix: dotcms-dev:latest incorrectly overwritten by nightly builds #34765 (companion bug — nightly overwriting dotcms-dev:latest;
  both are about gating :latest correctly).
• NA (no Freshdesk ticket).

[erickgonzalez]

Working as it should. LTS releases don't update latest tag anymore