fix(ci): give the manual-merge prod gitops PR its own branch name

[milandufek]

Problem

create-staging-pr and create-manual-merge-prod-pr both declare needs: [prepare-build, build-helmreleases], so they start at the same time. In prepare-pr-metadata, the is_staging branch and the else (manual-merge prod) branch both derived the same branch name:

branch_name="${repo_name}/${commit_hash}"    # commit_hash = ${GITHUB_SHA::8}

Both jobs then race to push that ref into gitops-deployments, and the loser dies with:

! refs/heads/gooddata-ruby/8870a381:refs/heads/gooddata-ruby/8870a381
  [remote rejected] (cannot lock ref 'refs/heads/gooddata-ruby/8870a381': reference already exists)

which fails ready-to-merge and gets the PR ejected from the merge queue. The SHA changes on every queue attempt but the in-run collision does not, so retries fail identically — PR #2092 failed the gate twice this way (run 1, run 2).

Why this surfaced only now

The colliding pair only runs when a helm chart changes. With prepare-build.outputs.charts == '[]', helm-charts-build skips → build-helmreleases skips → both PR jobs skip on build-helmreleases.result == 'success'. The last commit under k8s/charts/ was ca95a94e (2021-12-22), four years before this pipeline was written (d9c5393c / 3c2d6bab, Sept–Oct 2025). Every PR merged since has been image/code-only, so the two jobs had never both run until #2092 bumped lcm-bricks to 2.0.9.

Fix

Suffix the manual-merge prod branch with _prod, following the convention the auto-merge variant already uses (_${cluster}_automerge), and distinguish the commit message / PR title. The three names are now distinct and none is a path-prefix of another, so there's no git directory/file conflict either:

variant	branch
staging	gooddata-ruby/<sha>
auto-merge prod	gooddata-ruby/<sha>_<cluster>_automerge
manual-merge prod	gooddata-ruby/<sha>_prod

Retitling is safe — no consumer matches on the title: revert-staging-pr keys off commit_hash, create-pr-comment off pr_url.

Follow-up (not in this PR)

create-manual-merge-prod-pr runs in parallel with staging validation, so the prod PR always references a stable chart version that promote-to-stable has not produced yet. On #2092 promote-to-stable was skipped, leaving two orphaned prod PRs (gitops-deployments#26514, #26524) pointing 8 prod clusters at a stable/lcm-bricks:2.0.9 that does not exist. Worth a separate ticket for the ordering.

Testing

YAML parses (yq/ruby -ryaml); the prepare-pr-metadata shell logic was executed for all three input combinations to confirm distinct branch names. Full end-to-end verification requires a chart change going through the merge queue — #2092 is that change.

🤖 Generated with Claude Code

Summary by CodeRabbit

• Deployment
  • Production deployment pull requests now use clearer branch and title labels when targeting all production clusters.
  • Staging and auto-merge production deployment behavior remains unchanged.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: adf659a9-faa9-4bff-9233-7f411830a866

📥 Commits

Reviewing files that changed from the base of the PR and between aa29f8e and 6478053.

📒 Files selected for processing (1)

• .github/workflows/create-gitops-deployments-pr.yaml

Included review availability: 3 reviews are currently available. Your included PR review attempts over the past 7 days set your current allowance at 5 reviews per hour.

---

📝 Walkthrough

Walkthrough

The GitOps deployment workflow now uses a _prod branch suffix and explicit production-cluster text in commit and PR titles for applicable production deployments. Staging and auto-merge production behavior remains unchanged.

Changes

Production deployment naming

Layer / File(s)	Summary
Production branch and PR metadata .github/workflows/create-gitops-deployments-pr.yaml	Non-staging, non-auto-merge production deployments now use a _prod branch suffix and titles that identify deployment to all production clusters.

Estimated code review effort: 1 (Trivial) | ~5 minutes

Merge Risk: ⚪ Minimal · up to 64780

This localized change gives the manual-merge production GitOps PR a distinct branch name, preventing the documented branch collision. No actionable merge-blocking risk remains beyond normal checks and review.

Poem

I’m a rabbit in the deployment lane,
I hop through branches without strain.
_prod marks the path so clear,
Production clusters now appear.
Staging keeps its former way,
While GitOps PRs bloom today.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly identifies the CI fix that gives the manual-merge production GitOps pull request a distinct branch name.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0 files. (1 skipped: 1 unsupported.)
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

---

_{Comment @coderabbitai help to get the list of available commands.}