Tags created by `changeset tag` don't trigger workflows with `on.push.tags`

[Grsz]

Affected Packages

@changesets/cli

Problem

My original plan was to create a tag/version based deployment for my monorepo, where changesets would handle the versioning and tagging. I set up github actions workflows that are triggered on.push.tags.

At first I was using the workflow:

name: Version
permissions:
  pull-requests: write
  contents: write

on:
  push:
    branches:
      - main

concurrency: ${{ github.workflow }}-${{ github.ref }}

jobs:
  release:
    name: Release
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Setup
        uses: ./.github/actions/setup

      - name: Create Release Pull Request
        uses: changesets/action@v1
        with:
          createGithubReleases: false
          publish: pnpm changeset tag
        env:
          GITHUB_TOKEN: ${{ secrets.CHANGESET_GITHUB_TOKEN }}
          HUSKY: 0

I had some more complex workflows for deploying apps, but for demonstration say there is one workflow for creating tag for api. Running changeset, then changeset version then changeset tag should create tag api@0.0.1, which should trigger:

name: Test tag
permissions:
  pull-requests: write
  contents: write

on:
  push:
    tags:
      - api@[0-9]+.[0-9]+.[0-9]+

jobs:
  didirun:
    name: Did it run
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Checker
        run: echo YES!

Where everything works fine, I create the changeset, the PR is created for the version bump, and upon merging to main, it creates and pushes the tags.

The problem is it doesn't trigger the "Test tag" workflow.

I thought that based on this discussion the reason is because the tags are created by a bot, and I replaced the action's GITHUB_TOKEN with a PAT stored in secrets.CHANGESET_GITHUB_TOKEN. It didn't help.

Further debugging, I ran the whole flow manually locally (on main).

pnpm changeset
pnpm version
git commit -m "Version bump"
pnpm changeset tag
> 🦋  New tag:  api@0.0.3
> 🦋  New tag:  admin@0.0.3
> 🦋  New tag:  storefront@0.0.3
> 🦋  New tag:  service@0.0.3
git push
git push --tags
>  * [new tag]         api@0.0.3 -> api@0.0.3
>  * [new tag]         admin@0.0.3 -> admin@0.0.3
>  * [new tag]         storefront@0.0.3 -> storefront@0.0.3
>  * [new tag]         service@0.0.3 -> service@0.0.3

No workflow run.

Then I created a tag manually with

git tag api@0.0.999

and pushed it, then it triggered the workflow.

Then created an even more simplified version, deleted every package, every app except api, and the workflow has been triggered even with changeset.

I was quite frustrated at this point, but curiosity drove me forward to find out yet another of the many undocumented annoying behaviour of github actions in this discussion.

Apparently, if you push more than 3 tags at once, github actions will just ignore all of them, not running any workflows triggered by on.push.tags.

Proposed solution

The ideal solution would be to somehow demolish the hype around github actions so they will finally build something without weird behaviour that people are complaining about for years receiving hundreds of likes, so they finally wake up and at least document these behaviours so people don't have to research hours and days to manually figure out what's causing unexpected things. But I guess none of us can do anything about this, gh actions is the industry standard. Sorry for the rant.

Pushing tags one-by-one could work as proposed solution of this discussion.

Also, tags pushed by changesets/action@v1 don't trigger on.push.tags even when only one tag is being pushed, and even when a custom PAT is passed to env.GITHUB_TOKEN most likely because of this discussion. This one is not a priority though, I'll just ditch the action, and do the version bump and tagging manually, but not being able to trigger custom workflows for each app independently based on tag name if there are more than 3 is a blocker.

[Grsz]

Created a script:

#!/bin/bash

pnpm changeset tag

comm -23 \
  <(git tag --list | sort) \
  <(git ls-remote --tags origin \
    | awk '{print $2}' \
    | sed 's|refs/tags/||' \
    | sort) \
| while read tag; do
    echo "Pushing tag: $tag"
    git push origin "$tag"
  done

That successfully triggers tag based workflows in github actions. It filters unpushed tags, and pushes them one by one synchronously.

When using changesets/action@v1 to push the tags via the bot it still doesn't trigger workflow runs.

[Andarist]

Do you have a TLDR for me? 😅 Do you know what kind of a change we could introduce to make it work out of the box?

[Grsz]

TL;DR:

• if more than 3 tags are pushed at once, github actions workflows triggered by on.push.tags won't run. See discussion. When version bump is happened to more than 3 packages, changeset will tag each of them, and push them at once, and tag triggered workflows won't run. One possible solution is pushing tags one-by-one synchronously as per the above comment.
• as in changesets/action the user is set to the github actions bot, any events created by it won't trigger any workflows. See docs and discussion. This means that the same workflow that depends on a tag push is triggered if you push a matching tag, but if the tag is pushed by the github actions bot, it won't trigger it. I don't have a proposed solution for this.

This is a design flaw of github actions, not changesets itself, and I'm surprised this isn't being flagged more frequently, but for those who have deployments depending on tag pushes this is a real pain to deal with.

[antony]

I have this exact problem. I think for a more generic use-case, yes, a way of pushing tags out-of-band (as your script does) would be a desirable feature.

Possibly a feature of the changesets action, rather than changesets itself, however.

[h3rmanj]

I'm running into this as well. release-please-action works around this if you pass a token other than the GITHUB_TOKEN. I tried generating a token with the same app I use for release-please, but workflows still weren't triggered by the tag, so I assume it has to do with the way changeset-action pushes the tag.

[h3rmanj]

I dug a little into how release-please-action pushes the tag, vs how changeset-action pushes the tag.

It seems that release-please creates the tag though the Create a release api by supplying tag_name and target_commitish. When doing this with a PAT or GitHub App, tag workflows are then triggered.

Changeset action however;

• runs the publish command (which creates a tag locally)
• runs git push --tags
• then creates releases through the github api with existing tags

If the action was changed to not run git push --tags, and provide target_commitish when creating releases, workflows should be able to work if a token other than the built-in GITHUB_TOKEN is provided.

[h3rmanj]

This is now possible by using commitMode: github-api introduced in changesets/action#391, with a PAT or GitHub App Token.

[oowliq]

This is now possible by using commitMode: github-api introduced in changesets/action#391, with a PAT or GitHub App Token.

Thank you, this is the only solution that worked for me!