feat: PR-based release flow for alpha; test suite proving all three release properties

[Copilot]

Alpha published on every push with no human gate. Master had no automated tests proving the trigger conditions were correct. Both gaps are addressed here.

Flow change: alpha now mirrors master

Event	Before	After
PR merged into alpha (touches packages/**)	publishes immediately	creates alpha release PR
Alpha release PR merged	n/a	publishes with alpha npm tag
PR merged into master	creates release PR	unchanged
Master release PR merged	publishes with latest tag	unchanged

create-release-pr.yml

• Add alpha to on.push.branches
• Branch-detect to pick version strategy: alpha uses X.Y.Z-alpha.N → X.Y.Z-alpha.(N+1) (or (major+1).0.0-alpha.1 if no alpha suffix yet); master uses npm patch-increment
• Alpha PR: branch chore/alpha-release-vX, title chore: alpha release vX, --base alpha
• Loop guards extended: chore: alpha release v and /alpha-release-v added to if: skip condition

publish.yml

• Remove push: branches: alpha trigger entirely
• Add alpha to pull_request.branches; update if: to match base.ref == alpha && title starts with 'chore: alpha release v'
• Simplify checkout ref: — always a PR event now, no push/PR ternary needed

bump-and-publish.js

• Remove alpha auto-increment, version-restore heuristic, commit, and branch-push
• Add getNpmAlphaVersion() via npm view less dist-tags.alpha
• Alpha validates package.json > npm dist-tags.alpha (same pattern as master vs npm latest)
• Both branches: only the annotated tag is pushed; no local commits created

Test suite (scripts/test-release-automation.js, 34 tests, npm run test:release)

Proves all three required properties without GitHub auth or npm credentials:

Section	What it proves
1 — publish.yml conditions	Master release PR → publish; alpha release PR → publish; everything else → skip
2 — create-release-pr.yml conditions	Normal merges trigger; both release PR title flavours are loop-guarded
3 — Alpha version increment logic	Pure-function tests: 5.0.0-alpha.1 → 5.0.0-alpha.2, double-digit rollover, non-alpha seed
4 — bump-and-publish master path	Uses existing version, no commit, no branch push, rejects stale version
5 — bump-and-publish alpha path	Same as master; rejects missing -alpha. suffix; publishes with alpha tag
6 — create-release-pr no-op safety	Commit created when needed; clean exit + no gh calls when version unchanged

Original prompt

Create a new pull request in less/less.js (base branch: master) that fixes the release automation introduced in PR #4430 so that:

Goal

Merges to master (that are not merges of the release PR itself) should create or update a release branch/PR that bumps versions. When that release PR is merged, the publish workflow should publish to npm.

This PR should focus only on correcting the scripts/workflows for this automation; do not refactor unrelated parts.

Background / context

PR #4430 (merged) introduced a PR-based release flow for master:

• A workflow .github/workflows/create-release-pr.yml that runs on pushes to master (paths under packages/**) and creates/updates a chore: release vX.Y.Z PR with version bumps.
• A publish workflow .github/workflows/publish.yml that publishes on alpha direct pushes and on master when a release PR is merged.
• A script scripts/bump-and-publish.js used during publishing.

Copilot PR review feedback in #4430 highlighted a key correctness issue in create-release-pr.yml: when there are no staged changes (git diff --cached --quiet), the workflow still pushes and may attempt gh pr create, which fails with “no commits between head and base”. Fix this so the workflow exits early (or at least skips PR creation) when there’s no new commit to create for the release branch.

Requirements / acceptance criteria

1. Create Release PR workflow works on normal merges to master

   • On push to master affecting packages/**, the workflow must either:
     • create a new release branch chore/release-v<next_version> off origin/master, commit version bumps, push the branch, and open a PR to master, OR
     • if the release branch already exists, update it deterministically and ensure the PR exists.

2. No infinite loop

   • The create-release-pr workflow must not re-trigger itself endlessly when the release PR is merged. Keep or improve the existing guards.

3. No-op safety

   • If bumping versions results in no file changes (branch already at the desired version), the workflow must not:
     • attempt to create a PR with no commits between head and base,
     • fail the job for this reason.
   • It should exit cleanly after confirming whether an existing PR already exists.

4. Publish on release PR merge

   • Ensure .github/workflows/publish.yml triggers npm publish when (and only when) the release PR is merged into master.
   • Ensure it does not run publishing on ordinary merges to master that are not release merges.

5. Keep alpha behavior intact

   • Existing alpha direct-push publishing behavior should remain unchanged.

Implementation notes

• Prefer minimal, targeted changes.
• Use shell safety: set -euo pipefail where appropriate.
• If needed, add explicit checks like:
  • detect whether a commit was created in the workflow run,
  • detect whether a PR exists before attempting gh pr create,
  • skip gh pr create if there are no commits.
• Consider making PR creation idempotent: if PR exists, update it; if not and there’s a commit, create it.

Deliverables

• A new PR with code changes implementing the above.
• Include a concise PR description explaining:
  • when release PRs are created,
  • when publishing happens,
  • what guards prevent loops/no-ops.

Relevant existing review note from #4430 to address:

• In .github/workflows/create-release-pr.yml, if git diff --cached --quiet is true (no version changes), workflow still pushes and may attempt gh pr create and can fail with “no commits between head and base”. Fix by exiting early / skipping PR creation in that case.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: I can't get copilot to fix this -- read through the comments please and see where I was trying to get Copilot to resolve the issue: @less/less.js/pull/4430

Assistant: I pulled the review comment threads that exist on less/less.js#4430 and the commit list for the PR. What I can’t see from the data returned is the full “PR conversation” (top-level PR description discussion, your back-and-forth with Copilot SWE Agent, etc.). The tool output only included Copilot Pull Request Reviewer’s 3 inline comments plus the PR’s commit list.

That said, those inline review threads make it pretty clear where you were trying to steer Copilot, and what remained incomplete.

What you were trying to get Copilot to resolve (and why)

Your core goal (as the PR title says) was:

Ensure an npm publish is always backed by a GitHub tag, release, and a version-bump commit that exists on the canonical branch (master), i.e. avoid “published version has no corresponding master commit”.

The tricky part you were trying to force the automation to respect is:

• On master, you want a PR-based version bump (so the bump commit is merged into master normally).
• But the publish step ...

This pull request was created from Copilot chat.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[coderabbitai]

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 3c99c41e-ce75-44ca-a74d-5ef78a00a935

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 copilot/fix-release-automation-scripts

📝 Coding Plan

• Generate coding plan for human review comments

---

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

Tip

You can disable poems in the walkthrough.

Disable the reviews.poem setting to disable the poems in the walkthrough.