fix: ensure npm publish is always backed by a GitHub tag, release, and version-bump commit by Copilot · Pull Request #4430 · less/less.js

Copilot · 2026-03-17T17:50:47Z

The publish script silently swallowed git push failures and continued to publish to npm anyway, causing versions to appear on npm with no corresponding tag, GitHub release, or version-bump commit in master. The root cause was that the original try/catch around the push steps swallowed branch protection errors, so npm received a new version while GitHub had neither the updated package.json nor the tag.

The fix adopts a PR-based release flow for master that keeps all four things in sync without requiring any branch-protection bypass:

NPM version — published by the script after the release PR merges
package.json in master — updated by the release PR itself before merging
GitHub tag and release — tag is created and pushed by the script; gh release create runs in the workflow after publish
Changelog — maintainers update CHANGELOG.md on the release branch before merging

How it works

code PR merges to master
        │
        ▼
create-release-pr.yml fires
(only when packages/** changed)
        │
        ▼
"chore: release vX.Y.Z" PR created/updated
with bumped package.json on chore/release-vX.Y.Z branch
        │  (maintainer adds CHANGELOG entries, then merges)
        ▼
publish.yml fires on pull_request: [closed]
(only when PR title matches "chore: release v*")
        │
        ▼
bump-and-publish.js creates tag at HEAD,
pushes tag, publishes to npm

Changes

.github/workflows/create-release-pr.yml (new) — triggers on push to master when packages/** files change. Skips if the push is itself a release PR merge. Determines the next patch version from the npm registry, creates or resets a chore/release-vX.Y.Z branch with the bumped package.json, and opens a pull request if one doesn't already exist.
.github/workflows/publish.yml — master trigger changed from on: push to on: pull_request: [closed]. The job only runs when a PR whose title starts with chore: release v is merged into master. The alpha branch retains its existing direct-push flow. CI/script-only PRs (.github/**, scripts/**) are excluded from triggering the alpha push path via paths-ignore.
scripts/bump-and-publish.js — the branch push (git push origin master) is removed for master. The version bump is already committed to master via the release PR, so only the annotated git tag needs to be pushed. The alpha branch retains its existing commit + branch-push behaviour.

Why this avoids branch-protection issues

Tag pushes (refs/tags/*) are not subject to the "require pull request" branch-protection rule. The version-bump commit reaches master through a normal PR merge, so no bypass is required.

Original prompt

This section details on the original issue you should resolve

<issue_title>npmjs package version not aligned with GitHub repository sources and tags bug (again)</issue_title>
<issue_description>To reproduce:

N/A

Current behavior:

Similar to #4394

There is a 4.6.4 version available at https://www.npmjs.com/package/less

There is no 4.6.4 release in the GitHub repository

Current version in master is 4.6.3

less.js/package.json

Line 4 in 48a386f

"version": "4.6.3",

Expected behavior:

If there is a 4.6.4 version on npmjs, there is also a 4.6.4 release in GitHub

If there is a 4.6.4 version on npmjs, there is also a commit where the version is changed to 4.6.4 in GitHub

This time nothing except the version has changed in the package, so it is easier to assess there is no issue, but it is still time consuming.

Environment information:

N/A
</issue_description>

<agent_instructions>Is this an issue in our publishing script? Is this a real issue? Are we actually using releases for anything?</agent_instructions>

Comments on the Issue (you are @copilot in this section)

Fixes npmjs package version not aligned with GitHub repository sources and tags bug (again) #4429

📱 Kick off Copilot coding agent tasks wherever you are with GitHub Mobile, available on iOS and Android.

…sion bump commits Co-authored-by: matthew-dean <414752+matthew-dean@users.noreply.github.com>

matthew-dean · 2026-03-17T19:23:50Z

@copilot Why was it failing though? Will the underlying failure cause this to stop working entirely?

matthew-dean · 2026-03-17T19:24:19Z

"A secondary risk: if the version-bump commit pushed back to master re-triggered the workflow, it would auto-increment and publish another version with zero code changes." -- @copilot did you address this?

matthew-dean · 2026-03-17T19:24:58Z

@copilot Also, what did you think about this comment: #4429 (comment)

…ranch protection Co-authored-by: matthew-dean <414752+matthew-dean@users.noreply.github.com>

Copilot · 2026-03-17T19:29:46Z

@copilot Why was it failing though? Will the underlying failure cause this to stop working entirely?

The exact failure was a GitHub branch protection rule on master (run #34 logs):

remote: error: GH006: Protected branch update failed for refs/heads/master.
remote: - Changes must be made through a pull request.
remote: - Required status check "CodeRabbit" is expected.
remote: - You're not authorized to push to this branch.

The script tried to push a "chore: bump version to X.Y.Z" commit back to master, which branch protection always blocks. The original try/catch silently swallowed that, so npm got the new version while GitHub had neither the commit nor the tag.

My initial fix (making the push fatal) was correct in principle but would have permanently broken publishing since that branch push will always fail.

The proper fix (8902b33) removes the version-bump commit and branch push entirely. Now the script:

Updates package.json files locally only (no commit)
Creates an annotated git tag at the current HEAD (the actual code commit)
Pushes only the tag — tag pushes (refs/tags/*) are not subject to branch protection "require pull request" rules
Publishes to npm

This keeps npm and GitHub in sync without ever needing to bypass branch protection. The getTargetVersion logic already handles master's package.json being behind npm (it reads the npm registry version and auto-increments from there).

Copilot · 2026-03-17T19:32:53Z

"A secondary risk: if the version-bump commit pushed back to master re-triggered the workflow, it would auto-increment and publish another version with zero code changes." -- @copilot did you address ...

Yes, that risk is fully eliminated. Since the script no longer creates a version-bump commit or pushes anything to the master branch, the workflow can never be re-triggered by its own output. The only thing pushed is the tag, and tag pushes don't trigger on: push: branches: [master] workflows.

@copilot Also, what did you think about this comment: #4429 (comment)

The comment proposes two approaches:

Option 1 — automation commits a version bump: This is what the original script tried to do, but master has branch protection rules (GH006: changes must be made through a pull request) that permanently block the Actions bot from pushing directly. To make this work we'd need either a PAT with admin bypass rights, or a workflow that opens a PR for the version bump and auto-merges it — significant complexity for a cosmetic change.

Option 2 — don't track version in source, make it a publish-time concern: This is essentially what the current fix does in practice. The package.json in master reflects the version from the last merged PR. The publish script reads the npm registry to determine the next version, so package.json's version isn't even used as the source of truth for the increment. The tag on GitHub remains the canonical record of what was published and when.

Given the branch protection constraint, Option 2 (current approach) is the pragmatic choice: every npm publish is backed by a pushed tag pointing to the exact code that was published, and the tag is what gh release create uses. The only visible difference from Option 1 is that package.json in master won't show 4.6.X after each publish — it'll show whatever version was in the last merged PR. I think that's an acceptable trade-off, but worth flagging if you want a different policy.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

https://api.github.com/repos/less/less.js/issues/4429/comments
- Triggering command: /usr/bin/curl curl -s REDACTED (http block)

If you need me to access, download, or install something from one of these locations, you can either:

Configure Actions setup steps to set up my environment, which run before the firewall is enabled
Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

matthew-dean · 2026-03-17T20:14:06Z

@copilot

The proper fix (8902b33) removes the version-bump commit and branch push entirely.

Uh... okay I'm not sure this is sufficient.

This is essentially what the current fix does in practice. The package.json in master reflects the version from the last merged PR. T

I think that's all I'm trying to ascertain. At the end of this process, will the master branch be aligned in terms of:

The published NPM version
The latest package.json IN master version
The releases version
The changelog details version

That's my requirement. If I need to update the ability to update master directly for the repo just for github actions, I can do so.

coderabbitai · 2026-03-17T20:14:18Z

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: f0b8b66e-bb7a-4206-b23a-f98ff794219b

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-npm-package-version-alignment

📝 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 enable review details to help with troubleshooting, context usage and more.

Enable the reviews.review_details setting to include review details such as the model used, the time taken for each step and more in the review comments.

…guard Co-authored-by: matthew-dean <414752+matthew-dean@users.noreply.github.com>

Copilot · 2026-03-17T20:18:33Z

@copilot

The proper fix (8902b33) removes the version-bump commit and branch push entirely.
...

Done in f791453. After the publish run, the four things will be aligned as follows:

NPM version ✅ — published by the script
package.json in master ✅ — the script now commits chore: bump version to X.Y.Z and pushes it to master (push is fatal, so npm publish is blocked if this step fails)
GitHub tag/release ✅ — tag is pushed before npm publish; gh release create runs in the workflow after publish
Changelog — this was never auto-generated by the publish script. CHANGELOG.md is manually maintained by maintainers through PRs. The GitHub release notes point to CHANGELOG.md, but the file itself needs to be updated by hand before the release PR is merged.

One action required on your side: the master branch protection must allow github-actions[bot] to push directly — otherwise the branch push will fail fatally and block publishing. In GitHub → Settings → Branches → master → "Allow specified actors to bypass required pull requests" → add github-actions[bot].

The workflow also has the infinite-loop guard restored (!startsWith(github.event.head_commit.message, 'chore: bump version to')), so the version-bump commit pushing back to master will not re-trigger a second publish run.

matthew-dean · 2026-03-17T21:44:28Z

@copilot One more thing... for PR merges like this that don't affect code, how do we make sure we don't kick off a publish?

Co-authored-by: matthew-dean <414752+matthew-dean@users.noreply.github.com>

Copilot · 2026-03-17T21:45:39Z

@copilot One more thing... for PR merges like this that don't affect code, how do we make sure we don't kick off a publish?

Added .github/** and scripts/** to paths-ignore in b4beeab. A push that only touches CI/workflow or publish-script files will now be skipped. Any PR that also touches code in packages/ will still trigger a publish as expected.

matthew-dean · 2026-03-17T21:52:08Z

@copilot

One action required on your side: the master branch protection must allow github-actions[bot] to push directly — otherwise the branch push will fail fatally and block publishing. In GitHub → Settings → Branches → master → "Allow specified actors to bypass required pull requests" → add github-actions[bot].

ChatGPT says you're on crack. That's not possible. It says, "Use a PR-based release flow". Can we do that instead? Start a release PR (Like "Release v{x.x.x}" with the actual version) that updates if we merge any other PR (but keeps the same next version)? And then when that "special" PR merges to master, THEN it publishes?

Co-authored-by: matthew-dean <414752+matthew-dean@users.noreply.github.com>

Copilot · 2026-03-17T22:02:23Z

@copilot

One action required on your side: the master branch protection must allow github-actions[bot] to push directly — otherwise the branch push will fail fatally and block publishing. In Gi...

Done in ee04ec4. The flow now works exactly as you described, with no branch-protection bypass needed:

Code PR merges to master → create-release-pr.yml fires (only when packages/** changed) and creates/updates a chore: release vX.Y.Z PR on a chore/release-vX.Y.Z branch with the bumped package.json. Maintainers can add CHANGELOG entries to this branch before merging.
Release PR merges → publish.yml fires (pull_request: [closed] where title startsWith('chore: release v')). The version is already in package.json from the PR, so the script only creates + pushes the git tag and publishes to npm.

CI/script-only PRs (touching only .github/**, scripts/**, etc.) don't touch packages/** so they never trigger create-release-pr.yml, and they certainly can't satisfy the chore: release v PR title gate for publish.yml.

matthew-dean · 2026-03-18T17:21:35Z

@copilot I merged #4427 after this. Why didn't it create a PR for the release? Please investigate and fix it.

Copilot

Pull request overview

Introduces a PR-based release flow for master to keep npm publishes aligned with the corresponding version-bump commit, Git tag, and GitHub release—while retaining the existing direct-push publishing flow for alpha.

Changes:

Add a new workflow to automatically create/update a chore: release vX.Y.Z PR after package changes land on master.
Change the publish workflow so master publishes only when a release PR is merged (and alpha continues to publish on direct pushes).
Update the publish script to avoid pushing master directly and to push only tags for master releases.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
`scripts/bump-and-publish.js`	Adjusts push behavior to avoid pushing `master` directly; pushes tags for releases.
`.github/workflows/publish.yml`	Switches `master` publishing to occur on merged release PRs; keeps `alpha` on push with additional guards.
`.github/workflows/create-release-pr.yml`	Adds automation to create/update a release PR that bumps versions after package changes merge to `master`.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

scripts/bump-and-publish.js

+  // For master the version-bump commit already lives in master (it came from
+  // the release PR).  Only push the git tag — tag pushes bypass branch
+  // protection "require pull request" rules.
+  // For alpha (direct-push branch) we still push the bump commit to the branch.
+  if (!isMaster) {
+    console.log(`📤 Pushing to ${branch}...`);
+    if (!dryRun) {
      execSync(`git push origin ${branch}`, { cwd: ROOT_DIR, stdio: 'inherit' });
-      execSync(`git push origin "${tagName}"`, { cwd: ROOT_DIR, stdio: 'inherit' });
-    } catch (e) {
-      console.log(`⚠️  Push failed, but continuing with publish...`);
+    } else {
+      console.log(`   [DRY RUN] Would push to: origin ${branch}`);
    }
+  }
+
+  console.log(`📤 Pushing tag ${tagName}...`);
+  if (!dryRun) {
+    execSync(`git push origin "${tagName}"`, { cwd: ROOT_DIR, stdio: 'inherit' });
  } else {


scripts/bump-and-publish.js

      console.error(`   - ${name}: ${error}`);
    });
-    console.error(`\n⚠️  Note: Version bump and commit were successful.`);
+    console.error(`\n⚠️  Note: Version bump commit and tag were pushed successfully.`);


.github/workflows/create-release-pr.yml

+          git add package.json packages/*/package.json
+          if git diff --cached --quiet; then
+            echo "No version changes; branch is already at v${NEXT_VERSION}"
+          else
+            git commit -m "${TITLE}"
+          fi
+
+          # --force-with-lease refuses to overwrite if the remote has advanced
+          # past what we fetched, which protects against concurrent workflow
+          # runs.  This is intentional: if two code PRs land simultaneously the
+          # second run will fail-fast here and the release branch stays coherent.
+          git push origin "${RELEASE_BRANCH}" --force-with-lease
+
+          # Open a PR if one doesn't already exist for this version.
+          EXISTING=$(gh pr list --head "${RELEASE_BRANCH}" --base master \
+            --json number --jq '.[0].number' 2>/dev/null || echo "")
+
+          if [ -z "${EXISTING}" ]; then
+            BODY="## Release v${NEXT_VERSION}


matthew-dean · 2026-03-19T17:56:21Z

@copilot Okay can you make a new PR with fixes that will make a merge to master CORRECTLY make a release PR?

Initial plan

d44f1f1

Copilot AI assigned Copilot and matthew-dean Mar 17, 2026

Copilot started work on behalf of matthew-dean March 17, 2026 17:50 View session

fix: prevent npm publish when GitHub push fails, skip workflow on ver…

4c09402

…sion bump commits Co-authored-by: matthew-dean <414752+matthew-dean@users.noreply.github.com>

Copilot AI changed the title ~~[WIP] [BUG-123] Fix npm package version not aligned with GitHub sources~~ fix: ensure npm publish is always backed by a GitHub tag and release Mar 17, 2026

Copilot AI requested a review from matthew-dean March 17, 2026 17:56

Copilot finished work on behalf of matthew-dean March 17, 2026 17:56

Copilot started work on behalf of matthew-dean March 17, 2026 19:23 View session

fix: skip version-bump commit entirely, push only the tag to bypass b…

8902b33

…ranch protection Co-authored-by: matthew-dean <414752+matthew-dean@users.noreply.github.com>

Copilot finished work on behalf of matthew-dean March 17, 2026 19:30

Copilot started work on behalf of matthew-dean March 17, 2026 19:31 View session

Copilot finished work on behalf of matthew-dean March 17, 2026 19:33

matthew-dean marked this pull request as ready for review March 17, 2026 20:14

Copilot started work on behalf of matthew-dean March 17, 2026 20:14 View session

matthew-dean mentioned this pull request Mar 17, 2026

fix(less): upgrade make-dir to v4 to fix security vulnerability #4426

Merged

3 tasks

fix: restore version-bump commit + push to master, add infinite-loop …

f791453

…guard Co-authored-by: matthew-dean <414752+matthew-dean@users.noreply.github.com>

Copilot AI changed the title ~~fix: ensure npm publish is always backed by a GitHub tag and release~~ fix: ensure npm publish is always backed by a GitHub tag, release, and version-bump commit Mar 17, 2026

Copilot finished work on behalf of matthew-dean March 17, 2026 20:19

Copilot started work on behalf of matthew-dean March 17, 2026 21:44 View session

fix: exclude .github and scripts from publish workflow trigger

b4beeab

Co-authored-by: matthew-dean <414752+matthew-dean@users.noreply.github.com>

Copilot finished work on behalf of matthew-dean March 17, 2026 21:47

Copilot started work on behalf of matthew-dean March 17, 2026 21:52 View session

feat: implement PR-based release flow for master

ee04ec4

Co-authored-by: matthew-dean <414752+matthew-dean@users.noreply.github.com>

Copilot finished work on behalf of matthew-dean March 17, 2026 22:03

matthew-dean merged commit efd8b82 into master Mar 17, 2026
7 checks passed

matthew-dean requested a review from Copilot March 19, 2026 16:58

Copilot started reviewing on behalf of matthew-dean March 19, 2026 16:58 View session

Copilot AI reviewed Mar 19, 2026

View reviewed changes

Copilot AI mentioned this pull request Mar 19, 2026

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

Merged

Conversation

Copilot AI commented Mar 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

How it works

Changes

Why this avoids branch-protection issues

Comments on the Issue (you are @copilot in this section)

Uh oh!

matthew-dean commented Mar 17, 2026

Uh oh!

matthew-dean commented Mar 17, 2026

Uh oh!

matthew-dean commented Mar 17, 2026

Uh oh!

Copilot AI commented Mar 17, 2026

Uh oh!

Copilot AI commented Mar 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

I tried to connect to the following addresses, but was blocked by firewall rules:

Uh oh!

matthew-dean commented Mar 17, 2026

Uh oh!

coderabbitai bot commented Mar 17, 2026

Review skipped

Uh oh!

Copilot AI commented Mar 17, 2026

Uh oh!

matthew-dean commented Mar 17, 2026

Uh oh!

Copilot AI commented Mar 17, 2026

Uh oh!

matthew-dean commented Mar 17, 2026

Uh oh!

Copilot AI commented Mar 17, 2026

Uh oh!

Uh oh!

matthew-dean commented Mar 18, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

matthew-dean commented Mar 19, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Copilot AI commented Mar 17, 2026 •

edited

Loading

Copilot AI commented Mar 17, 2026 •

edited

Loading