Tags not pushed if it's scoped without @ prefix

The real problem

Turns out, naming my package alexaka1/package was the issue. This is a perfectly valid name, on npm i would need an @ prefix to my name, but I dont use npm. So this should be fine. And IT IS, if used via git-cli.

Original issue

I have switched to using a dedicated github app, to automate releases.

Here is the workflow in question:

name: "Version packages"
on:
  push:
    branches:
      - main
concurrency: ${{ github.workflow }}-${{ github.ref }}-changesets
permissions:
  contents: read
jobs:
  check-release:
    name: Prepare release
    runs-on: ubuntu-24.04-arm
    environment: release
    timeout-minutes: 10
    defaults:
      run:
        shell: bash
    permissions:
      pull-requests: write
      contents: write
      issues: read
      id-token: write
    steps:
      # ...
      - name: Generate Github App token to create releases
        uses: actions/create-github-app-token@29824e69f54612133e76f7eaac726eef6c875baf # v2.2.1
        id: app-token
        with:
          app-id: ${{ secrets.RELEASE_BOT_APP_ID }}
          private-key: ${{ secrets.RELEASE_BOT_PRIVATE_KEY }}
      - name: Checkout code
        uses: actions/checkout@8e8c483db84b4bee98b60c0593521ed34d9990e8 # v6.0.1
        with:
          persist-credentials: false
          fetch-depth: 0
      - name: GitHub API only supports non-executable files and directories
        # https://github.com/changesets/action/issues/523
        run: git ls-files | while read -r file; do [ -x "$file" ] && chmod -x "$file" || true; done
      # pnpm install ...
      - name: Create Release Pull Request or Prepare release
        id: changesets
        uses: changesets/action@e0145edc7d9d8679003495b11f87bd8ef63c0cba # v1.5.3
        with:
          version: pnpm run version
          publish: pnpm exec changeset publish
          commitMode: 'github-api'
          createGithubReleases: 'true'
        env:
          GITHUB_TOKEN: ${{ steps.app-token.outputs.token }}

config.json:

{
  "$schema": "https://unpkg.com/@changesets/config@3.0.4/schema.json",
  "changelog": ["@changesets/changelog-github", { "repo": "alexaka1/distroless-dotnet-healthchecks" }],
  "commit": false,
  "fixed": [],
  "linked": [],
  "access": "restricted",
  "baseBranch": "main",
  "updateInternalDependencies": "patch",
  "ignore": [],
  "privatePackages": {
    "version": true,
    "tag": true
  }
}

The github app in question has these permissions:

Read access to issues and metadata
Read and write access to code and pull requests

I assume this is enough.

The logs show this when running:

Run changesets/action@e0145edc7d9d8679003495b11f87bd8ef63c0cba
  with:
    version: pnpm run version
    publish: pnpm exec changeset publish
    commitMode: github-api
    createGithubReleases: true
    setupGitUser: true
  env:
    PNPM_HOME: /home/runner/setup-pnpm/node_modules/.bin
    GITHUB_TOKEN: ***
setting git user
setting GitHub credentials
No changesets found. Attempting to publish any unpublished packages to npm
No user .npmrc file found, creating one
/home/runner/setup-pnpm/node_modules/.bin/pnpm exec changeset publish
🦋  success found untagged projects:
🦋  alexaka1/distroless-dotnet-healthchecks@1.5.2
🦋  New tag:  alexaka1/distroless-dotnet-healthchecks@1.5.2

However the tag is not pushed (nor is the release created) and I have no idea why. The reason I switched to github app instead of the implicit token is because I have setup push triggers on tags.

I do also have rulesets setup:

Additionally require signed commits, and block force pushes are also ticked.

Here is what works:

PR creation for version bumps, with signed commit, ie: Version Packages alexaka1/distroless-dotnet-healthchecks#993
using the git-cli to create and push tags, (by using the release bot's token as PAT) ie: https://github.com/alexaka1/distroless-dotnet-healthchecks/releases/tag/alexaka1%2Fdistroless-dotnet-healthchecks%400.0.0-20251222144934

So the github app token retriaval works fine, otherwise it would not be able to create the PR and push commits.
And the rulesets also work fine, otherwise it would not be able to push the git tag via cli, because only the bot user is allowed to do that.

I swear to god, I have f-ing had it with GitHub and it's stupid limitations...

So sanity check, folder prefixes in tags are legal on github. And it does work with this action via git cli. Ie foo/bar@1.1.1

However this does not work with commitMode github-api 🤡

I was shooting in the dark and on a hunch removed the prefix. https://github.com/alexaka1/distroless-dotnet-healthchecks/releases/tag/distroless-dotnet-healthchecks%401.5.2 viola, instantly created a release.

This is not about slash. It's about using

  "access": "restricted",

In your config. And this is a safety net. If you are using a private registry the expected package name convention is starting with @ symbol such as @blabla

If you are using npmrc or some private registry you can safely change the access from restricted to public in config and all will be fine.

The package.json has private: true enabled. I do not care about NPM rules, plus it does not work with changesets tag either, which is just supposed to tag it.

Plus the cli prints that new version found.

There is zero indication on why it should not work, in fact there is literally no distinction made between when it does work, and when it doesn't in the log messages, or the source code.

ci: revert commitMode github-api (known tag-push bug)

ci: use GitHub App token for release PRs (#105)

This is likely related to our very clunky tag detection regex:

action/src/run.ts

Line 101 in 1bf7c27

let newTagRegex = /New tag:\s+(@[^/]+\/[^@]+|[^/]+)@([^\s]+)/;

Which wouldn't capture and push the tag for you if it doesn't start with @ for scope-ish packages. So I'm not sure how git-cli fixed it for you, but this bug should've happened in both cases.

Anyways, I think we have plans to make the tag detection more robust while we're prepping for the next major.

@bluwy

Which wouldn't capture and push the tag for you if it doesn't start with @ for scope-ish packages. So I'm not sure how git-cli fixed it for you, but this bug should've happened in both cases.

@bluwy I didn't use @ in the name, as I'm not using changesets to manage npm packages. I'm using it to manage external libs. So package.json is only a means to an end, in my use case I'm not publishing anything to NPM. So my "packages" in changeset are named foo/bar without the NPM registry required @ prefix.

I get that. I didn't mean you have to use @ here. Just that it's what changesets expect for any tracked packages, npm or not, to push the tags for you.

The system put in place with changesets/changesets#2129 and #678 should fix this.

Navigation Menu

Repository navigation

Tags not pushed if it's scoped without `@` prefix #553

The real problem

Original issue

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tags not pushed if it's scoped without @ prefix #553

Description

The real problem

Original issue

Activity

alexaka1 commented on Dec 22, 2025

furcan commented on Dec 24, 2025

alexaka1 commented on Dec 25, 2025

bluwy commented on Jun 14, 2026

alexaka1 commented on Jun 16, 2026

bluwy commented on Jun 16, 2026

Andarist commented on Jul 1, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Tags not pushed if it's scoped without `@` prefix #553