Rebase and atomically push commit with tag in publish workflow

[Thejus-Paul]

Summary

• Upgrade actions/checkout and actions/setup-node to v5, and EndBug/add-and-commit to v10.
• Set push: false on add-and-commit so the version-bump commit is created locally but not pushed.
• Replace the separate push step with a script that rebases onto latest origin/main, creates the v${VERSION} tag, and pushes the commit and tag together via git push --atomic.

Why

Pushing the commit and tag in one atomic operation prevents races where main advances between the commit and tag pushes, and avoids non-fast-forward failures when other PRs land during the release run.

Test plan

• Merge a PR with a release label and confirm the workflow rebases, tags, pushes atomically, and publishes to npm.

[neeto-bugwatch]

🤖 NeetoBugWatch Review

I've analyzed your pull request and found some potential improvements that might be worth considering. Please review the specific line comments below for helpful suggestions.

💡 To trigger a re-review of this PR, add a comment with neeto-bugwatch-run on its own line (not inside a code block or blockquote).

Warning

Verdict: Needs review — 3 comments found, including major issues

Click to copy prompt for AI agent

Verdict: review_required

The following are code review comments from an AI reviewer that only has access
to the PR diff, not the full codebase. Treat every comment as a hypothesis,
not a fact. For each comment:

1. Investigate the verification questions against the full codebase first.
2. Go beyond the provided questions. Use your full codebase access to ask your
   own questions, check related code paths, and consider edge cases that the
   reviewer could not have seen from the diff alone.
3. Only implement the suggested fix if your investigation confirms the issue is real.
4. If the issue is not real, skip it entirely. Do not implement speculative fixes.

Prioritize by severity (critical > major > minor > trivial) and confidence score.
Only attend to comments with confidence below 0.5 if your investigation proves them valid.

[
  {
    "file_path": ".github/workflows/publish.yml",
    "line_number": 78,
    "comment": "The `+` prefix in `+refs/tags/v${VERSION}` forces the tag push to the remote. Force-pushing tags is generally risky because it mutates existing releases, which can break downstream consumers and package registries that depend on immutable release tags.",
    "confidence": 0.95,
    "severity": "major",
    "suggested_fix": "Remove the `+` prefix (i.e., use `refs/tags/v${VERSION}`) to push the tag safely. The push will then rightfully fail if the tag already exists remotely.",
    "verification_questions": [
      "Do downstream consumers or automated systems rely on these release tags being strictly immutable?",
      "Is there a valid operational reason to force-push over existing release tags in this pipeline?"
    ]
  },
  {
    "file_path": ".github/workflows/publish.yml",
    "line_number": 23,
    "comment": "Removing the pinned SHA and using `@v5` reduces supply chain security. Furthermore, `actions/checkout` defaults to `fetch-depth: 1` (a shallow clone). When you later run `git rebase origin/main`, it may fail if the remote branch has advanced beyond the local shallow commit history.",
    "confidence": 0.9,
    "severity": "major",
    "suggested_fix": "Add `fetch-depth: 0` to the checkout step's `with` block to ensure the full history is available for the rebase step. Additionally, consider pinning back to a specific commit SHA to maintain strong supply chain security.",
    "verification_questions": [
      "Does the remote 'main' branch frequently receive commits while this workflow is running?",
      "Have there been intermittent rebase failures in this workflow due to missing commit history?"
    ]
  },
  {
    "file_path": ".github/workflows/publish.yml",
    "line_number": 77,
    "comment": "Using `git tag -f` forcefully overwrites the tag if it already exists. In a release pipeline, this can silently mask issues where a version bump was forgotten, leading to multiple different releases carrying the same version tag locally.",
    "confidence": 0.85,
    "severity": "minor",
    "suggested_fix": "Remove the `-f` flag so the command fails loudly when attempting to tag an already existing version.",
    "verification_questions": [
      "Are version tags intended to be overwritten and mutated in this repository?",
      "What should happen if a workflow run triggers without the package version being bumped?"
    ]
  }
]

[neeto-bugwatch]

The + prefix in +refs/tags/v${VERSION} forces the tag push to the remote. Force-pushing tags is generally risky because it mutates existing releases, which can break downstream consumers and package registries that depend on immutable release tags.

Click to see review metadata

{
  "confidence": 0.95,
  "severity": "major",
  "suggested_fix": "Remove the `+` prefix (i.e., use `refs/tags/v${VERSION}`) to push the tag safely. The push will then rightfully fail if the tag already exists remotely.",
  "verification_questions": [
    "Do downstream consumers or automated systems rely on these release tags being strictly immutable?",
    "Is there a valid operational reason to force-push over existing release tags in this pipeline?"
  ]
}