Add lockstep release workflow to main (dispatch-only)

[umair-ably]

What

Brings exactly two files from #684 (pubsub-split/release-tooling) onto main:

• .github/workflows/release.yml — the lockstep ably-pubsub-core + ably-pubsub-server release workflow
• scripts/release_preflight.py — the pre-flight it (and check.yml's dry-run job) calls

Nothing else from #684 comes with it: no CONTRIBUTING.md, no /release skill, no pyproject.toml/LICENSE changes, no uv.lock change.

Why

GitHub only registers a workflow_dispatch workflow once its file exists on the default branch. The PubSub split work merges to integration/v4 and will not reach main until GA, so without this the lockstep release workflow cannot be dispatched at all. This is plan step 15b, and it mirrors the sibling ably-ruby#455 ("Add lockstep release workflow to main (dispatch-only)").

⚠️ Before merging

Merging this replaces main's tag-triggered, single-distribution publish workflow.

Tag-triggered runs execute the workflow file as it exists at the tagged commit, so releases of the legacy ably 3.x package are unaffected — but only as long as they are tagged from a maintenance branch, not from main. After this merges, a v3.x.y tag cut from main would run the two-distribution workflow and fail the pre-flight instead of publishing ably.

Therefore, as a merge precondition:

1. maintenance/3.x (name TBC org-wide — plan step 24) must be cut from main before this PR merges. It keeps today's unchanged single-distribution release.yml.
2. From that point on, all 3.x fixes and all v3.* tags go to that branch only.

Please do not merge until (1) is done.

What this enables

Once on main, the workflow is dispatchable against any ref that carries the split layout:

gh workflow run release.yml --ref pubsub-split/release-tooling -f version=0.0.1a0
gh workflow run release.yml --ref integration/v4 -f version=4.0.0rc1 -f publish=true

Used for:

• the PyPI name claim for ably-pubsub-core / ably-pubsub-server via pending trusted publishers, immediately after the repo rename (plan steps 1 and 16);
• prereleases cut from split branches, and the deliberate guardrail tests (re-run at the same version → both skipped; mismatched version → pre-flight aborts with nothing uploaded).

Inert on main

• Dispatched at main, the pre-flight refuses the single-distribution layout before anything is built or uploaded.
• Publishing would additionally require trusted publishers bound to this repo + release.yml for the two new project names, which do not exist yet.

To make that refusal legible rather than a FileNotFoundError traceback, two small changes were made (both no-ops on the split layout, and #684 should pick up the same two so the copies do not diverge):

1. scripts/release_preflight.py gains a require_split_layout() guard, called first in main().
2. release.yml runs the build-free version-site pre-flight right after uv sync, before uv build --package ably-pubsub-core — which on main would otherwise be the first thing to fail, with an unhelpful "package not found in workspace" error.

Verification

• yaml.safe_load on the workflow: OK.
• actionlint .github/workflows/release.yml: clean.
• ruff check scripts/release_preflight.py: clean.
• Pre-flight run locally on main's layout exits 1 with:

pre-flight: this workflow releases the split distributions (ably-pubsub-core and
ably-pubsub-server), but this ref still has the single `ably` layout — no
core/pyproject.toml or server/pyproject.toml. There is nothing here to release in
lockstep. Dispatch this workflow against a ref that has the split layout (--ref
integration/v4, or a pubsub-split/* branch); releases of the legacy `ably`
distribution are cut from its maintenance branch with that branch's own
single-distribution release.yml.

🤖 Generated with Claude Code

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

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.}