skip ci prevents followup publish workflow run after merging release PR

[airtonix]

Greetings, you have reached the true utopia of promises!

<angel voices>

except reality is

So lets recap the expected outcome of using this action...

• have a github repo
• have a workflow configured for push event that runs changeset/action on your default branch.
• have nodejs code with package.json
• have changesets installed
• use changesets to record md files for feature/fix PRs
• merge feature/fix PRs
• default branch push event workflow should run
• changeset/action should create "Release PR" (because it finds .changeset/!(README)*.md)
• merging "Release PR" should trigger push event on your default branch (same workflow)

If you just follow all the documentation you might just be cunning enough to get the "Release PR" to show up.

If you use the default ${{ secrets.GITHUB_TOKEN }} for everything, then that's as far as you get... no more Crème Brûlée for you! ✋🏻 👮🏻

So now you dive into the issue tickets with your search fu and sword of perseverance...

You find that:

• Bruh, you should use a Personal Access Token
• Or maybe you need "everything the permissions"

So lets say you get there, you work out what scopes you need in your Personal Access Token...

name: Release Package

on:
  push:
    branches:
      - master

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

jobs:
  release:
    runs-on: ubuntu-latest

    permissions:                                                  // 1️⃣ 
      id-token: write                                             
      contents: write                                             
      packages: write                                             
      pull-requests: write                                        
      issues: read                                                

    steps:
      #
      # Checkout code and fetch more history so we can do interesting things
      # with tools that compare changes across commitrefs
      - uses: actions/checkout@v3
        with:
          token: ${{ secrets.YOUR_BOT_PAT_TOKEN }}                // 2️⃣ 
          fetch-depth: 0

      #
      # Setup development/build tooling
      - name: Provision
        uses: ./.github/actions/setup-tooling

      #
      # This step configures NPM
      #
      # - here we configure the registry for publishing
      - name: Setup publishing
        uses: actions/setup-node@v2
        with:
          registry-url: "https://npm.pkg.github.com"              // 3️⃣ 

      - name: Dependencies
        uses: ./.github/actions/install-dependencies

      - name: Setup service bot git
        env:
          GIT_EMAIL: ${{secrets.YOUR_BOT_GIT_EMAIL}}
          GIT_NAME: ${{secrets.YOUR_BOT_GIT_NAME}}
        run: |
          git config --local user.email "${GIT_EMAIL}"            // 4️⃣ 
          git config --local user.name "${GIT_NAME}"              //  

      - name: Create Release Pull Request or Publish to npm
        id: changesets
        uses: changesets/action@v1
        with:
          publish: npm run release
          setupGitUser: false                                     // 5️⃣
          title: Deploy Release
        env:
          GITHUB_TOKEN: ${{ secrets.YOUR_BOT_PAT_TOKEN }}         // 6️⃣  
          NPM_TOKEN: ${{ secrets.YOUR_BOT_PAT_TOKEN }}            // 7️⃣ 
          NPM_AUTH_TOKEN: ${{ secrets.YOUR_BOT_PAT_TOKEN }}       // 8️⃣ 

1. This customises the permission level of the ${{secrets.GITHUB_TOKEN}} used throughout this job. If you've changed the action settings in your REPO to just make it all write then this might not be needed.
2. Because you can't let the github bot make any commits, you also need to now check the repo out with your own PAT
3. if you're publishing to somewhere else other than npmjs.org, then welcome to this curve ball 🤝
4. since we can't let github think that its own github bot made commits, we need to configure it to something other than the github bot git user details, see more 👇🏻
5. again, we don't want github thinking its bot did anything.
6. need to set
7. all the tokens yo!
8. This one is special because you also used actions/setup-node@v2 to configure your registry

But you're not out of the woods yet!...

Rolling like this, your "Version Packages" PR when merged will have in its commit message the hilariously troll like marker:

[skip ci]

As a result, you still don't get a follow up workflow run.

So i have slain all the monsters in the dungeon only to discover that the all the loot is glitched and i cant pick it up or perhaps i am in the wrong dungeon?

how do we get make the follow up action run when we merge our "Version Packages" pr ?

---

default github bot git user:

git config --local user.email "41898282+github-actions[bot]@users.noreply.github.com"
git config --local user.name "github-actions[bot]"

[airtonix]

@Andarist Could it be as simple as that that we need to update documentation to inform users to disable the "commit": true in the .changesets/config.json ?

[airtonix]

confirmed.

you either need to configure @changeset/cli to not auto commit when you record changesets or you need to configure your github repo to only allow squash merges and always use the pr title and message as the merge commit.

[vnphanquang]

Hey @airtonix I don't know if you have figured out your problem but I can confirm some of these:

• Yes, events triggered by the GITHUB_TOKEN will not create a new workflow run. You have to replace it with personal access token
• Yes, [skip ci] and some other similar strings won't trigger follow up workflow run
• Yes, since you are using the action I don't think there is any reason to set the commit config to true

With those said, however, the act of merging a PR will trigger an push event in any matching workflow, assuming of course you are merging yourself, not some bot, and you don't have the [skip ci] string (maybe you can explicitly set the title & commit input args for the action?).

Another important thing that took me a while to realize is that changesets/action is meant to run multiple times, for every push to baseBranch (check in .changeset/config.json whether your baseBranch is set correctly): if there is no PR opened, it will open one, if there is, it will update it, and if the PR is merged, it will do the publishing work. So we shouldn't trigger another follow-up workflow but in fact trigger the same changesets/action one (not sure if this is the problem you're having).

Here is my workflow:

name: changesets
on:
  push:
    branches:
      - main
  workflow_dispatch:

jobs:
  Version:
    timeout-minutes: 15
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v3
        with:
          fetch-depth: 0
      - name: Setup pnpm
        uses: pnpm/action-setup@v2
        with:
          version: 7.6.0
      - name: Setup node
        uses: actions/setup-node@v3
        with:
          node-version: 16
          cache: pnpm
      - name: Install dependencies
        run: pnpm install --frozen-lockfile
      - name: Create release PR or Publish to npm
        uses: changesets/action@v1
        with:
          version: pnpm ci:version # changeset version
          publish: pnpm ci:publish # pnpm build && changeset publish
          commit: "chore(release): changesets versioning & publication"
          title: "Changesets: Versioning & Publication"
          createGithubReleases: true
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

Push to main => changesets/action opens PR => merge PR => changesets/action publish packages

I am working with a turborepo - pnpm monorepo setup, having migrated from semantic-release. You can have a look at my repo here. Everything works pretty nicely currently, including the automatically published github releases even though some people have filed issues with it.

Also I know you are suffering over there but I couldn't help but have a laugh reading your issue description.

[wijionejs]

@vnphanquang thanks for the clarification I was looking for. I had been struggling to understand the workflow of this action before I finally found your comment that changesets/action is meant to run multiple times.

So, If i understand correctly: If there's some changesets in a merged pr (pushed commit) - the action either creates a new one or updates an existing pull request, but doesn't run publish script. If there's no changesets in a merged pr (pushed commit) - the action skips the part with creating/updating pr and immediately runs publish script from step.with.publish.

Correct me if I'm wrong please.

[vnphanquang]

@wijionejs yes pretty much. We can look at the actual source code of the action at https://github.com/changesets/action/blob/main/src/index.ts#L49-L116 (the switch cases pretty much tell us what's up)

For me, i know that i only do publishing by merging a PR with changesets, so i added a path filter for my changsets action just to save some resources. Also I added a workflow_dispatch hatch just so I can manually trigger the action when necessary.

name: changesets
on:
  push:
    branches:
      - main
+    paths:
+      - ".changeset/**"
+      - ".github/workflows/changesets.yaml"
+  workflow_dispatch:

My action is at https://github.com/vnphanquang/svelte-put/blob/main/.github/workflows/changesets.yaml#L7-L8 if helpful

[wijionejs]

@vnphanquang, great, thanks for the link to source code of the actions, it becomes even easier to understand how it works under the hood!

[yashsway]

@vnphanquang thanks for providing the source and explaining your context! this was actually really helpful for my situation.