PR created but action not started

You can see that the PR is opened correctly: clibuilder/clibuilder#375
But there is no workflow started: https://github.com/unional/clibuilder/actions

I'm setting it up using shared workflow:

jobs:
  code:
    uses: unional/.github/.github/workflows/yarn2-library-verify-cross-platform.yml@main

  release:
    uses: unional/.github/.github/workflows/yarn2-library-release.yml@main
    needs: code
    secrets: inherit

https://github.com/unional/clibuilder/blob/main/.github/workflows/release.yml

      - name: Create Release Pull Request or Publish to npm
        id: changesets
        uses: changesets/action@v1
        with:
          version: yarn changeset version
          publish: yarn changeset publish
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

https://github.com/unional/.github/blob/main/.github/workflows/yarn2-library-release.yml

Maybe somehow the action is getting wrong information because of that?

I have another repo with the same problem:
stable-packages/store#118

Same here! Qiskit/web-components#83

Same here! Milkdown/milkdown#531

Hey guys
I'm not sure that what I'm experiencing is the same issue, but it seems related
For me, when the 'Version Packages' pr is created, the workflow I have do run
But when I merge other changes to master (with a changeset file), and the 'Version Packages' pr is being updated, the workflow doesn't run anymore.
This is the workflow I'm refering to:
yishayweb/monorepo_pnpm_changesets
and as you can see, I'm triggering it with
on: pull_request: types: [opened, synchronize, reopened, edited] branches: - master
Hence I expect it to be run each time the 'Version Packages' pr is getting updated
Is it the issue you guys experience?

same issue in my private repo

@yishayweb

@yishayweb you can turf all that custom code to test if changesets exist and use either:


      - uses: dorny/paths-filter@v2
        id: filter
        with:
          base: ${{ github.ref }}
          filters: |
            Changesets:
              - added|modified: '.changesets/!(README)*.md'

            Apps:
              - 'apps/!(*storybook)**/*'

      - run: node -e 'console.log(${{toJson(steps.filter.outputs)}})'

or you can just use the changesets/cli status command with the json output:

https://github.com/changesets/changesets/tree/main/packages/cli#status

From GitHub docs:

When you use the repository’s GITHUB_TOKEN to perform tasks, events triggered by the GITHUB_TOKEN will not create a new workflow run. This prevents you from accidentally creating recursive workflow runs. For example, if a workflow run pushes code using the repository’s GITHUB_TOKEN, a new workflow will not run even when the repository contains a workflow configured to run when push events occur.

Use a repo scoped Personal Access Token (PAT) created on an account that has write access to the repository that pull requests are being created in. This is the standard workaround and recommended by GitHub. However, the PAT cannot be scoped to a specific repository so the token becomes a very sensitive secret. If this is a concern, the PAT can instead be created for a dedicated machine account that has collaborator access to the repository. Also note that because the account that owns the PAT will be the creator of pull requests, that user account will be unable to perform actions such as request changes or approve the pull request.

So the solution could be this:

       env:
-         GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+         GITHUB_TOKEN: ${{ secrets.CUSTOM_GITHUB_TOKEN }}
          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

CUSTOM_GITHUB_TOKEN needs to be generated and added to repo secrets. Note that the name of a secret cannot start with GITHUB_.

@kachkaev

Yes, @kachkaev's answer is the correct one. Would you be so kind to add a note about this in the README of this action?

I’m still a bit confused by these tokens actually. After setting a custom GitHub token in blockprotocol/blockprotocol#510, I saw a new PR authored by the corresponding user and CI ran fine. However, after mere PRs got merged into main, the updates in ‘Version Packages’ PR still came from github-actions[bot] and so CI did not re-run.

First Commit Actions (full set):

Actions for one of subsequent force-pushes (no checks for on: pull_request):

Merging is blocked:

Seems like the custom GITHUB_TOKEN env is not used when creating commits 🤔 Or maybe it is used, but this is trumped by commit metadata Author: github-actions[bot] <github-actions[bot]@users.noreply.github.com>.

Any tips anyone?

I tried configuring custom git credentials in https://github.com/blockprotocol/blockprotocol/pull/535/files

        env:
+         GIT_AUTHOR_EMAIL: custom-value@example.com
+         GIT_AUTHOR_NAME: Custom Value
+         GIT_COMMITTER_EMAIL: custom-value@example.com
+         GIT_COMMITTER_NAME: Custom Value
          GITHUB_TOKEN: ${{ secrets.CUSTOM_GITHUB_TOKEN }}
          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

However, this did not help. Here is what I see in the ‘Version Packages’ PR:

Commit metadata matches new environment variables that I’ve set:

commit 7fda46e1286e2b815b5f94b76e8532ce491edcd5 (HEAD, origin/changeset-release/main)
Author: hashdotai <63675132+hashdotai@users.noreply.github.com>
Date:   Thu Aug 25 12:53:17 2022 +0000

    Version Packages

The push though is still done by github-actions[bot] so checks are not triggered. 🤔 Because Linting is a required check, the PR cannot be merged unless a developer force-pushes to the branch just before releasing new versions.

This is surprising to me and, unfortunately, I don't know the answer to this problem. Perhaps it would be worth opening a ticket with GitHub support to learn what are the exact requirements for workflows to be executed. However, if I take a look at this commit and the related PR then I can see that workflows were correctly executed for both. So perhaps this is an issue in your setup. As far as I can see they only provide a custom token and nothing more:
https://github.com/developit/microbundle/blob/60b5edcf5d96c26877134febbdf0a247ee56b9c7/.github/workflows/release.yml#L34

@Andarist

Thanks for sharing a link to developit/microbundle#958 @Andarist!

If we look at individual commits in this PR, we can see the same pattern as in blockprotocol/blockprotocol#529. The first commit has ✅, but all the following force-pushed ones lack CI checks (1, 2, 3, ...). All commits are authored by github-actions[bot] despite GITHUB_TOKEN: ${{ secrets.REPO_SCOPED_TOKEN }} in release.yml.

The PR is then closed and reopened, which seems to work as a trigger for GitHub Actions. CI runs for the latest github-actions[bot]’s commit but is marked as triggered by a human.

I tried closing and re-opening blockprotocol/blockprotocol#529 too and this did trigger GitHub Actions. That’s a bit hacky but I don’t see any alternatives at this point. Unless I miss something, redefining GITHUB_TOKEN only changes the author of the PR and triggers actions for the first commit in it.

This is bizarre... 🙈 it would really be lovely if we could create a GitHub support ticket about this. Would you be willing to do this? You already have all the required context to explain the issue properly

I think I figured it out. Here is my final solution:

 jobs:
   release:
     runs-on: ubuntu-latest
     if: github.repository == 'org/repo'
     steps:
       - uses: actions/checkout@v3
+        with:
+          token: ${{ secrets.CUSTOM_GITHUB_TOKEN }}

       - uses: ./.github/actions/warm-up-repo
 
       - name: Create Release Pull Request or Publish to npm
         uses: changesets/action@v1.3.0
         with:
           publish: yarn changeset publish
         env:
+          GITHUB_TOKEN: ${{ secrets.CUSTOM_GITHUB_TOKEN }}
           NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

release.yml

When the action calls git push, it uses the same token as the one that was used during checkout. This explains why setting GITHUB_TOKEN only in changesets/action does not change the account that has force-pushed.

Resulting PR: blockprotocol/blockprotocol#542

CI runs for each new commit:

Now that I know that closing and reopening a PR replaces GITHUB_TOKEN, I wonder if it’s actually better. 😅 If every new push to ‘Version Packages’ triggers all GitHub workflows, that’s quite a few CI minutes wasted 😬

If every new push to ‘Version Packages’ triggers all GitHub workflows, that’s quite a few CI minutes wasted 😬

Yeah, in theory, you could craft a more complex pipeline that would wait for the CI checks on your base branch before updating the versioning PR and skip jobs there because they would be somewhat redundant if you have already run jobs on the base branch. It would be great to block the ability to merge the versioning PR when there is a pending CI job on the base branch too.

Would you be willing to add all of this information to the README, with the tradeoffs mentioned there?

fix: move app checkout step to the front and use token for checkout

@Andarist

@Andarist

As @shawnthye-guru mentioned, I think this might best be solved with having the version PR always created and updated in draft mode. You could avoid wasting CI minutes with a if: github.event.pull_request.draft == false check in your job, and only have it run when you mark the version PR as ready for review with

on:
  pull_request:
    types: [opened, reopened, synchronize, ready_for_review]

This cleans up the closing then immediately reopening noise in the PR as well as suggested above.

#258 is a good start, with @altano's #258 (comment) highlighting the importance of not just creating the version PR in draft mode, but also any subsequent updates should be keep the PR in draft mode as well.

I just tried this trigger block out which worked for our purposes (fast workflow):

  pull_request_review:
    types: [submitted]
    branches:
      - main

This is in addition to the pull_request trigger for non release PRs.

chore(ci): release workflow uses custom token

chore(ci): release workflow uses custom token (#3136)

chore(ci): release workflow uses custom token

chore(ci): release workflow uses custom token (#3136)

FWIW, I found a partial workaround for those who might have issues with PAT / GitHub App

You can use a deploy key to commit the changes, so it'll trigger the workflow run, as opposed to GITHUB_TOKEN.

It's important to note that this is a partial workaround because the initial trigger (e.g., when the release PR is opened) is still authored by the GITHUB_TOKEN, meaning that only subsequent commits to the release PR will trigger the workflows.

Here's a PR showing the changes I've made to make it work (you'll also need to generate an SSH key and set it as a secret)

We need to document this pattern but I feel the easiest workaround to this issue is to:

create a GitHub App (allowed to be installed only in your organization), on a settings page like this one: https://github.com/organizations/changesets/settings/apps
you don't have to host it anywhere, just install it in a repository
"Generate a private key" in its settings and share it in your repo's secrets - or even better, creae a "version" environment and share it in its secrets
mint its token in your workflow and pass that to changesets/action, like here

After #257 was merged in, my recommended approach above has been working great for us. We have the PR open and then update in draft mode. Then our CI triggers on an additional ready-for-review event for PRs, kicking off our required checks before merging only once the release PR has been marked ready for review.

Navigation Menu

Repository navigation

PR created but action not started #187

16 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

PR created but action not started #187

Description

Activity

unional commented on May 23, 2022

abdonrd commented on May 25, 2022

Saul-Mirone commented on May 26, 2022

yishayweb commented on May 29, 2022

sindrisig commented on Jun 1, 2022

airtonix commented on Jul 14, 2022

kachkaev commented on Aug 19, 2022

Andarist commented on Aug 20, 2022

kachkaev commented on Aug 25, 2022

kachkaev commented on Aug 25, 2022

Andarist commented on Aug 25, 2022

kachkaev commented on Aug 25, 2022

Andarist commented on Aug 25, 2022

kachkaev commented on Aug 26, 2022

Andarist commented on Aug 26, 2022

16 remaining items

itrew commented on Jun 6, 2025

alexkb0009 commented on Jul 29, 2025

StyleShit commented on Jun 10, 2026

Andarist commented on Jun 10, 2026

itrew commented on Jun 11, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions