ci(lint): allow long-running branches in promotion PRs

[parth0025]

Summary

Fix two CI workflow gaps that PR #216 (the first staging → main promotion) surfaced:

1. Branch-name validator rejected staging as a source branch
2. Commitlint failed on hundreds of legacy commits that predate our Conventional Commits enforcement

Both fixes are scoped specifically to promotion PRs (source = staging or main). Normal feature-branch PRs continue to be validated exactly as before.

Why this is needed

When you opened PR #216 (staging → main), 4 checks failed:

Check	Root cause
❌ Branch name matches convention	staging isn't in the allowlist — only <type>/<kebab>, release/v*, hotfix-backport/*, and bot branches were
❌ Commit messages (commitlint)	The PR has 269 commits; many predate #209's commitlint setup and don't follow Conventional Commits
❌ PR title (Conventional Commits)	Title was "Staging" instead of <type>: <desc> — fixable by edit, not a workflow gap
❌ Docker / Build & push image	The pre-#213 broken Dockerfile is still on staging — resolves when #213 lands

This PR fixes the first two. Title is your responsibility; Docker resolves when #213 merges.

Files changed (2)

File	Change
.github/workflows/branch-name.yml	Add LONG_RUNNING='^(staging|main)$' pattern to the allow-set; surface it in the help-text
.github/workflows/commitlint.yml	Add if: github.head_ref != 'staging' && github.head_ref != 'main' to the lint-commits job

Diff: +18 / -4 lines.

What changes — and what does NOT change

Promotion PRs (staging → main, main → hotfix)

Check	Before	After
Branch name	❌ Always failed	✅ staging and main accepted
lint-commits (per-commit validation)	❌ Always failed on legacy commits	⏭️ Skipped (job shows "Skipped" in CI)
lint-pr-title (PR title Conventional Commits)	✅ Ran	✅ Still runs — squash commit uses PR title
Docker / main.yml CI	✅ Ran as normal	✅ Still runs

Normal feature-branch PRs (feat/foo → staging, fix/bar → staging, etc.)

Check	Before	After
Branch name	✅ Validated	✅ Validated exactly the same — staging/main source is impossible for these
lint-commits	✅ Validated	✅ Validated exactly the same — head_ref is the topic branch
lint-pr-title	✅ Validated	✅ Validated

Zero relaxation of normal-PR validation. The carve-out is bounded to promotion scenarios.

Why we don't lose validation by skipping lint-commits on promotion PRs

When a staging → main promotion merges, the squash-merge button creates one new commit on main whose message is the PR title. That PR title is still validated by lint-pr-title (which we don't skip). So:

• ✅ The commit that actually lands on main always follows Conventional Commits
• ✅ The 269 legacy commits visible in the PR don't matter for main history once squashed
• ✅ release-please reads commits on main, which all come from squash-validated PR titles

The trade-off is: we trust the squash commit on merge to be the source of truth. The legacy commits visible in the staging history are not (and cannot be) retroactively rewritten.

Why the LONG_RUNNING pattern is safe

The pattern is anchored: ^(staging|main)$. It only matches the literal strings staging and main — nothing like staging-typo or main-fork would pass.

No one creates branches named staging or main other than the long-running ones (the repo would refuse anyway — those branches already exist).

Test plan

• After this PR merges, re-trigger CI on PR chore(release): promote staging to main for v14.0.27 #216 — the branch-name and lint-commits checks should pass (or skip, in the lint-commits case)
• Open a test PR with branch name staging (or any name matching staging/main exactly) → branch-name check passes
• Open a test PR with a malformed branch name like not-following-convention → branch-name check still fails (unchanged)
• Open a test PR with a bad commit message on a normal feature branch → lint-commits still fails (unchanged)
• Verify lint-pr-title runs on promotion PRs (it must — that's how the squash commit's message gets validated)

After this PR merges — what to do with PR #216

1. Click "Update branch" on PR chore(release): promote staging to main for v14.0.27 #216 to pick up these workflow fixes
2. Fix the PR title from "Staging" → chore(release): promote staging to main for v14.0.27 (or similar)
3. Wait for PR ci(docker): publish multi-arch images to GHCR + complete compose stack #213 (Docker) to merge so the Docker check resolves
4. Get 1 approving review
5. Squash-merge

🤖 Generated with Claude Code

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 2c4a6c3a-d734-4f19-a7a2-8d48a085be46

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch ci/promotion-pr-validation

---

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