fix(ci): gate Docker :latest and "Next Release" relabel to main only

[erickgonzalez]

Summary

• The -6 Release Process workflow can be dispatched from any branch, but it unconditionally pushed Docker :latest and relabeled GitHub issues tagged Next Release with the dispatched release_version.
• When the workflow was run from a non-main branch (e.g. 26.04.11), this overwrote :latest with a non-main image and stamped main-only fixes with a release version that did not actually contain them.
• Adds a github.ref_name == 'main' guard to the deployment phase's latest input and the release phase's update_github_labels input so these two side effects fire only when releasing from main.

Plugin updates, Artifactory deploy, javadocs upload, SBOM, and Slack notification remain controllable via their existing workflow inputs and are intentionally not branch-gated — they are legitimate from non-main release branches.

Closes #35651

Test plan

• Dispatch -6 Release Process from a non-main branch with a standard version (e.g. 26.04.11-01) and update_github_labels = true. Confirm:
  • The deploy-docker step does not push the :latest tag.
  • The release phase does not relabel Next Release issues.
• Dispatch -6 Release Process from main with a standard version. Confirm:
  • Docker :latest is pushed (existing behavior).
  • Next Release issues are relabeled (existing behavior).
• Dispatch from main with an LTS version (e.g. 26.04.11_lts_v01). Confirm :latest is not pushed (pre-existing LTS behavior preserved).

🤖 Generated with Claude Code

This PR fixes: #35651

[claude]

Claude finished @erickgonzalez's task in 1m 17s —— View job

---

Claude PR Review

• Read the changed workflow file
• Check what the latest and update_github_labels inputs control
• Verify github.ref_name is the right ref to gate on
• Check for edge cases
• Post review

---

The change is correct and well-scoped. Two minor things to consider, neither blocking.

Verification

• github.ref_name for workflow_dispatch resolves to the dispatched branch (e.g. main or 26.04.11), so it is the right thing to gate on here. It is the parent workflow's ref and is not affected by the release branch/tag created inside release-prepare-phase.yml.
• latest downstream behavior: cicd_comp_deployment-phase.yml:256,300 already AND-combines inputs.latest with docker_suffix == '', so the LTS / java-suffix paths still cannot push :latest. The gate added in this PR composes correctly with is_latest == 'true' — both must be true on top of the existing suffix check.
• update_github_labels downstream: cicd_comp_release-phase.yml:281 already guards on inputs.update_github_labels == true && inputs.java-version == ''. Gating at the caller is the right layer — keeps the reusable phase agnostic of branch policy.
• Other side effects from non-main (Artifactory deploy, plugins, javadocs, SBOM, Slack) are left input-controllable. Reasonable for maintenance-branch releases like 26.04.11.

Nits (non-blocking)

1. Hard-coded 'main'. If the default branch is ever renamed, this silently disables the latest tag and label relabel without anyone noticing. Marginally more robust to use github.event.repository.default_branch on workflow_dispatch. Not worth changing on its own unless you're already touching this file.

2. release_commit override + dispatched from main. A user can dispatch from main and pass a release_commit that is not actually on main. The gate would still allow :latest and the Next Release relabel even though the released code isn't from main's tip. That is the same exposure as before this PR (and arguably out of scope for bug(ci): release workflow overwrites :latest and relabels "Next Release" issues from any source branch #35651), but worth noting because the PR's framing — "stamped main-only fixes with a release version that did not actually contain them" — is the same failure mode. If you want to fully close that gap, the prepare phase could compare release_commit to origin/main and surface an on_main output to AND into both gates. Optional follow-up.

Summary

Clean fix. The two added && github.ref_name == 'main' guards address the stated symptom with no collateral damage to other release inputs. Test plan covers the three cases that matter (non-main, main, main+LTS).
• Branch: issue-35651-release-workflow-improvements

[wezell]

I like this.