ci: bump homolog versions on homolog merges

[namastex888]

Why

HML images are canonically built from homolog, and each homolog PR merge must advance the Omni build/version number on homolog so operators can control exactly which source/build is deployed.

The previous version.yml behavior violated that:

• pull_request.closed only watched dev.
• workflow_run admitted main but not homolog.
• the workflow always checked out and pushed dev, even for non-dev triggers.

That let the P7 code merge to homolog without a homolog-side version bump.

Fix

• Include homolog in PR-merge version triggers.
• Admit successful homolog CI push runs.
• Route the version bump target by trigger branch:
  • dev -> bump/push dev, npm tag next, release channel dev
  • homolog -> bump/push homolog, npm tag homolog, release channel homolog
  • main -> preserve existing behavior: latest/stable with bump carried on dev
• Serialize version jobs per target branch instead of one global version-dev group.

Local verification

bun scripts/verify-versions.ts
=> OK: 21/21 files match

git diff --check
=> passed

bun run typecheck
=> 21 successful / 21 total

Push-hook note

The local pre-push hook was run with Bun on PATH:

bun test
=> 3961 pass / 292 skip / 1 fail

The single isolated failure is pre-existing/local dependency drift outside this workflow patch:

packages/media-processing/__tests__/processors.test.ts
Cannot find package 'jszip'

This PR changes only .github/workflows/version.yml.

[gemini-code-assist]

Note

Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported.

[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: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 0d50cc6e-2b16-431e-b290-a5965e57d3a9

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 fix/homolog-version-bump-canon

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 0e72aac13f

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Prevent duplicate homolog version jobs

For a normal dev→homolog merge, this workflow now runs twice: the new pull_request.closed trigger for homolog starts one version job, and the CI push on homolog starts this workflow_run path because .github/workflows/ci.yml runs on homolog pushes and the merge commit message contains /dev. Both jobs check out/push homolog and publish @homolog, so a single promotion can advance the build number twice or race on the same tag/branch; the homolog workflow_run path should be excluded or otherwise deduplicated against the PR trigger.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Serialize by the branch actually being pushed

This concurrency key is based on the event name and triggering branch, but the main workflow_run path still sets push_ref=dev. A dev PR merge (version-pull_request-dev) and a main promotion (version-workflow_run-main) can therefore run concurrently while both later push to refs/heads/dev; because both derive the next version from the same fetched tags before either push, one job can fail its atomic push/tag or require a rerun. This regresses the previous single version-dev serialization for all dev writers.

Useful? React with 👍 / 👎.