v1.5.0 in default commitMode is breaking on tag push

[koalou]

Hello,

The new version of the action is breaking my release flow:

Run changesets/action@v1
setting git user
/usr/bin/git config user.name "github-actions[bot]"
/usr/bin/git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
setting GitHub credentials
No changesets found. Attempting to publish any unpublished packages to npm
Found existing user .npmrc file
Didn't find existing auth token for the npm registry in the user .npmrc file, creating one
/usr/bin/echo New tag: <app>@1.3.1
New tag: <app>@1.3.1
/usr/bin/git push origin v1.3.1
error: src refspec v1.3.1 does not match any
error: failed to push some refs to '<repo_url>'
Error: Error: The process '/usr/bin/git' failed with exit code 1
Error: The process '/usr/bin/git' failed with exit code 1

I have forced v1.4.10 to be able to release for now, let me know if there is something I can do to help debug the issue.

[Andarist]

It looks as if your projects has been versioned as monorepo (<app>@1.3.1 tag indicates that) but then it has not been detected as monorepo by getPackages (I thiiiink it followed the else branch in if (tool !== 'root') {):

action/src/run.ts

Lines 101 to 153 in 5f15b43

	if (tool !== "root") {
	let newTagRegex = /New tag:\s+(@[^/]+\/[^@]+|[^/]+)@([^\s]+)/;
	let packagesByName = new Map(packages.map((x) => [x.packageJson.name, x]));
	for (let line of changesetPublishOutput.stdout.split("\n")) {
	let match = line.match(newTagRegex);
	if (match === null) {
	continue;
	}
	let pkgName = match[1];
	let pkg = packagesByName.get(pkgName);
	if (pkg === undefined) {
	throw new Error(
	`Package "${pkgName}" not found.` +
	"This is probably a bug in the action, please open an issue"
	);
	}
	releasedPackages.push(pkg);
	}
	if (createGithubReleases) {
	await Promise.all(
	releasedPackages.map(async (pkg) => {
	const tagName = `${pkg.packageJson.name}@${pkg.packageJson.version}`;
	await git.pushTag(tagName);
	await createRelease(octokit, { pkg, tagName });
	})
	);
	}
	} else {
	if (packages.length === 0) {
	throw new Error(
	`No package found.` +
	"This is probably a bug in the action, please open an issue"
	);
	}
	let pkg = packages[0];
	let newTagRegex = /New tag:/;
	for (let line of changesetPublishOutput.stdout.split("\n")) {
	let match = line.match(newTagRegex);
	if (match) {
	releasedPackages.push(pkg);
	if (createGithubReleases) {
	const tagName = `v${pkg.packageJson.version}`;
	await git.pushTag(tagName);
	await createRelease(octokit, { pkg, tagName });
	}
	break;
	}
	}
	}

It would be great if you could check the result of that getPackages in your project + share your project structure.

[Andarist]

Note that I have released Changesets itself using this new version of the action just today and it worked fine. So your project has to have some slightly unusual configuration/setup 🤔

[koalou]

It is indeed a monorepo hosting a Svelte project with src, package.json, and so on at the root.

Running `console.log(await getPackages(process.cwd()))` from the root gives

{
  tool: {
    type: 'root',
    isMonorepoRoot: [AsyncFunction: isMonorepoRoot],
    isMonorepoRootSync: [Function: isMonorepoRootSync],
    getPackages: [AsyncFunction: getPackages],
    getPackagesSync: [Function: getPackagesSync]
  },
  packages: [
    {
      dir: '<git_root>',
      relativeDir: '.',
      packageJson: [Object]
    }
  ],
  rootPackage: {
    dir: '<git_root>',
    relativeDir: '.',
    packageJson: {
      name: '<name>',
      version: '1.3.1',
      private: true,
      scripts: [Object],
      devDependencies: [Object],
      type: 'module',
      dependencies: [Object]
    }
  },
  rootDir: '<git_root>'
}

So your project has to have some slightly unusual configuration/setup 🤔

At the very least, my workflow is probably unusual as I’m "manually" running changeset version before calling changesets/action in a workflow that is only run when a PR is merged into the stable branch. I know that’s not the intended way of doing things and I’m ok with you closing as something you don’t expect to work but it did until this version 🙂

Full workflow should it be useful

name: '[prod] Build and deploy Node project to Azure Web App'

on:
  pull_request:
    branches:
      - main
    types:
      - closed

concurrency:
  group: ${{ github.workflow }}
  cancel-in-progress: true

jobs:
  build:
    runs-on: ubuntu-latest
    environment:
      name: 'production'
      url: ${{ steps.deploy-to-webapp.outputs.webapp-url }}
    steps:
      - name: Checkout Repo
        uses: actions/checkout@v3
        with:
          # This makes Actions fetch all Git history so that Changesets can generate changelogs with the correct commits
          fetch-depth: 0
          token: ${{ secrets.PUSH_AS_LOU_TOKEN }}

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: 'npm'

      - name: Creating .npmrc
        run: |
          cat << EOF > "$HOME/.npmrc"
            //npm.pkg.github.com/:_authToken=$GITHUB_TOKEN
          EOF
        env:
          GITHUB_TOKEN: ${{ secrets.GPR_TOKEN }}

      - name: npm install dev deps
        run: |
          npm ci --no-audit

      - name: Update version
        run: |
          npx changeset version
          npm i --no-audit

      - name: Build
        run: npm run build --if-present

      - name: remove dev deps
        run: |
          npm ci --no-audit --omit=dev

      - name: Get name
        id: package-name
        run: echo "PACKAGE_NAME=`cat package.json | grep name | cut -d'"' -f 4`" >> $GITHUB_OUTPUT

      - name: Get version
        id: package-version
        run: echo "PACKAGE_VERSION=`cat package.json | grep version | cut -d'"' -f 4`" >> $GITHUB_OUTPUT

      - name: Commit and merge to develop
        run: |
          git add .
          git config user.email "<email>"
          git config user.name "<name>"
          git commit -m "Release version ${{ env.PACKAGE_VERSION }}"
          git checkout develop
          git pull
          git config user.email "<email>"
          git config user.name "<name>"
          git merge --no-ff main -m "Merge tag 'v${{ env.PACKAGE_VERSION }}' into develop"
          git push --all
          git checkout main
        env:
          PACKAGE_VERSION: ${{ steps.package-version.outputs.PACKAGE_VERSION }}

      - name: Create Github Release
        id: changesets
        uses: changesets/action@v1
        with:
          publish: echo ${{ env.PUBLISH }}
        env:
          PUBLISH: "New tag: ${{ steps.package-name.outputs.PACKAGE_NAME }}@${{ steps.package-version.outputs.PACKAGE_VERSION }}"
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

      - name: create version file
        run: |
          echo ${{ env.PACKAGE_VERSION }} > version
        env:
          PACKAGE_VERSION: ${{ steps.package-version.outputs.PACKAGE_VERSION }}

      - name: cleanup before upload
        run: |
          rm -rf .git .gitignore .changeset .github src static playwright-report test-results tests tools CHANGELOG playwright.config.ts postcss.config.js README.md codegen.yaml

      - name: 'Deploy to Azure Web App'
        id: deploy-to-webapp
        uses: azure/webapps-deploy@v2
        with:
          app-name: '<name>'
          slot-name: 'production'
          publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE_PROD }}
          package: .

EDIT: add collapse details tags to collapse outputs

[Andarist]

Which of those tools describes your monorepo best? https://github.com/Thinkmill/manypkg/tree/734a9a8c52243e4e10a851b8dedf1016977a3b5e/packages/tools/src

Could you check why the one that should be detected is not detected in your case? You can check what happens in the relevant isMonorepoRoot method of the specific tool implementation

[Andarist]

Actually, this action doesn't use the latest version of the referenced packages. So you'd have to look for the answer here: https://github.com/Thinkmill/manypkg/blob/b8b914441995ad267a490251d443665fb999e32b/packages/get-packages/src/index.ts

Which part of the workflow here is responsible for generating <app>@1.3.1 tag? I see a mention of PUBLISH env variable here but I don't think we support this anywhere.

[koalou]

Ooooh! Wait a sec, it seems I had a brain fart: monorepo is for several projects in a single repo, and this is not what I have… 🤦
I apologize, I don’t know why I said it was a monorepo… 🙇

So… this is a repo with a single Svelte project. It seems my echoing New tag: <name>@<version> (see collapsed section) was not the expected way to do things, sorry for that as well…
Changesets is naming the git tag v<version> anyway so it does indeed take the else branch in if (tool !== 'root') if I’m reading properly.

The response I had started to work on in case something is salvageable

Which part of the workflow here is responsible for generating @1.3.1 tag? I see a mention of PUBLISH env variable here but I don't think we support this anywhere.

I have to admit I didn’t document it and it has been years… but, IIRC: the action wasn’t generating the tag then breaking when trying to match the regex, so I used the publish input

with:
  publish: echo  ${{ env.PUBLISH }}

to override changesetPublishOutput with my own New tag: <name>@<version>.
env.PUBLISH is set using the Get name and Get version steps

Actually, this action doesn't use the latest version of the referenced packages. So you'd have to look for the answer here: https://github.com/Thinkmill/manypkg/blob/b8b914441995ad267a490251d443665fb999e32b/packages/get-packages/src/index.ts

This version doesn’t work because await findRoot(dir) doesn’t return a string. Changing to (await findRoot(dir)).rootDir returns

{
  tool: 'root',
  root: {
    dir: '<git_root>',
    packageJson: {
      name: '<name>',
      version: '1.3.1',
      private: true,
      scripts: [Object],
      devDependencies: [Object],
      type: 'module',
      dependencies: [Object]
    }
  },
  packages: [
    {
      dir: '<root_dir>',
      packageJson: [Object]
    }
  ]
}

[myabc]

This is also affecting our release workflow for https://github.com/opf/primer_view_components (we will need to peg an older version of changesets/action for the time-being).

v1.5.0 (and specifically 207dc3d) changes the behaviour of git push for the non-Octokit code path from:

    await exec("git", ["push", "origin", "--tags"]);

to:

    await exec("git", ["push", "origin", tag]);

The former will always succeed, whereas the latter will return non-zero if the tag has not been created locally.

[Andarist]

The former will always succeed, whereas the latter will return non-zero if the tag has not been created locally.

Could you tell me more about this scenario? When could that happen?

[HDinger]

The former will always succeed, whereas the latter will return non-zero if the tag has not been created locally.

Could you tell me more about this scenario? When could that happen?

We run the action with a custom publish script enabled, basically like this:

      - name: Create release pull request or publish to npm
        id: changesets
        uses: changesets/action@v1
        with:
          title: Release Tracking
          version: npm run changeset:version
          publish: script/changeset-publish
        env:

The changeset-publish script looked like this:

# Get the current version
PACKAGE_VERSION=$(jq '.version' --raw-output ./package.json)

# Check if the remote has the current version as a git tag
# If it doesn't, we echo "New tag:" which is what the changeset action expects https://github.com/changesets/action/blob/b98cec97583b917ff1dc6179dd4d230d3e439894/src/run.ts#L123
git ls-remote --exit-code --tags origin "v$PACKAGE_VERSION" || echo "New tag:"

Before the recent changes, this went though smoothly. Now, we had to change the script to create the local tag before printing "New tag:" because of the issue @myabc mentioned above.

[Andarist]

Does it mean that you were never pushing those tags out at all? If yes - then how published github releases looked like in your case? Did they just point to the current HEAD automatically?

[HDinger]

Did they just point to the current HEAD automatically?

Yes, this is what it boils down to.

[Andarist]

Could you show me how such a release looks like? If you could link me to it, that would be even more helpful

[HDinger]

Sure, here are some links:

• release.yml
• old script/changeset-publish that leads to the failure
• new script/changeset-publish that creates a local tag and thus passes
• Latest release run that failed
• Latest Release tracking PR
• Latest Release tag

Don't know if that is what you were looking for. Let me know, if you need anything else.