Push from Action does not trigger subsequent action

[Stummi]

I have an github action which sometimes pushes back to the repository, and I expect this push to trigger another action which configured with “on: push”, however this seems to not work. Is this intentional?

Sample repository to demonstate the issue: https://github.com/Stummi/workflow-playground/tree/master/.github/workflows

[weide-zhou]

Hi Stummi,

Glad to hear you in GitHub Community!

If an action 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.

Please create a personal access token in repo setting(write permission accordingly), replace GITHUB_TOKEN in your ‘inc-counter.yml’, code as below, thanks.

- name: Push changes
      uses: ad-m/github-push-action@master
      with:
        github_token: ${{ secrets.PAT}}

[creator1creeper1]

Works well. However, I wish this arbitrary limitation on GITHUB_TOKEN was removed.

[gemyago]

This limitation is significantly diminishing all the benefits that GITHUB_TOKEN brings. If I have to allocate a PAT to work around this limitation, then why would I use GITHUB_TOKEN in the first place?

[rea1shane]

RESOLVED:

As another comment and push action doc say, need add persist-credentials: false when checkout.

- uses: actions/checkout@v2
  with:
    persist-credentials: false # otherwise, the token used is the GITHUB_TOKEN, instead of your personal access token.

---

ISSUE:

Did I miss something? This action can't trigger another action which run when push.

workflow file:

name: Posts Sync

on:
  workflow_dispatch:

jobs:
  sync:
    name: Posts Sync
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v3
        with:
          submodules: true

      - name: Update
        run: |
          git submodule update --remote content/posts

      - name: Commit
        run: |
          git config --local user.name github-actions
          git config --local user.email github-actions@github.com
          git commit -am "Auto updated posts" || echo "No changes to commit"

      - name: Push
        uses: ad-m/github-push-action@master
        with:
          github_token: ${{ secrets.HUGO_SITE_GIT_TOKEN }}
          branch: ${{ github.ref }}

[brandocomando]

Agreed. Imo the limitation on the GitHub token should be removed and those that don't want their pushes from GitHub actions to kick off workflows can go about it using the already existing commit message format to do so.

[electrovir]

Apps (like Netlify) get triggered on pushes from actions using the GITHUB_TOKEN. Why can't our own workflows be triggered as well?

[Stummi]

This helped. Thank you!

[akerl]

Is there a plan for removing this limitation? Providing a personal access token grants the Action far greater privileges than it needs.

[xt0rted]

I’m using this same workflow with a second one triggered on pull_request. Even if I use a PAT my pull_request workflow doesn’t run when commits are pushed back to the PR branch. This is an example of my workflow https://gist.github.com/xt0rted/d0eac04e15a7cea80aa974a4448defef

[xt0rted]

The comments at https://github.hscsec.cnmunity/t5/GitHub-Actions/Push-from-action-even-with-PAT-does-not-trigger-action/m-p/46293/highlight/true#M6505 solved my issue.

I needed to add persist-credentials: false to my checkout step since it’s using v2.

[ianwalter]

This has been driving me CrAzY because it’s not intuitive and hard to find information about. Thank you for the workaround.

[AllanOricil]

it took me hours to find this post.

[stovmascript]

Shouldn’t adding one of these permissions (Workflow syntax for GitHub Actions - GitHub Docs) to the GITHUB_TOKEN and setting it to read be enough now?

[ewized]

Does this work?

[creator1creeper1]

It doesn't appear to work, even with permissions: write-all

[ayanamist]

You can set token argument of actions/checkout@v2 to your generated pat without using ad-m/github-push-action@master and git push it normally.

[ardove]

I know this is a fairly old discussion, but I think it'd be handy to be able to get a PAT for the user who initiated the action (for actions that are triggered via the workflow_dispatch event). Seems like this would provide a better audit trail than a static personal access token of like a "service account".

[scottw-kr]

I'm not sure my configuration is exactly the same as the accepted answer, but I just wanted to post that I created an multi-job workflow that bumped and committed a package.json version number and with concurrency rules, it canceled the current workflow and started up a new one. It did this 3 times until I manually stopped the workflow.

[tanrobotix]

Thank you, it took me several hours to find the issue~

[kahootali]

This is a big issue in our flow, I need to pull my trunk branch into feature branches in my CI/CD if there are changes there, but the pipeline doesn't get triggered because of this. There can be changes in my trunk branch which when merged into feature branch can fail the build, but the pipeline wont get triggered, also using PAT is not the best of options, I want to use default token rather than creating a token and making sure it doesn't expire, securing it, etc

[chriskapp]

I have also spent some time debugging this issue. I think GitHub will not allow triggering such workflows to prevent building recursive triggering of actions. The workaround is to use a PAT with the fitting permissions. I have also found this in the documentation s.

When you use the repository's GITHUB_TOKEN to perform tasks, events triggered by the GITHUB_TOKEN, with the exception of workflow_dispatch and repository_dispatch, 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.

s. https://docs.github.com/en/actions/security-guides/automatic-token-authentication

[LecrisUT]

They could use concurrency to limit. The same recursive issue would occur if we run manually gh workflow run manually after the git push. It would make more sense for github to keep track internally of the GITHUB_TOKEN and hence the source of the git push and the recursive depth, rather than have us blindly improvise an endless recursive workflow ourselves.

Here is some inspiration for anyone wanting to abuse this

[tekumara]

NB: for the GITHUB_TOKEN to trigger a workflow dispatch it will need permissions actions: write otherwise you'll hit the dreaded:

could not create workflow dispatch event: HTTP 403: Resource not accessible by integration

[LecrisUT]

Github seems to be very thorough in not allowing us to re-run CI workflows:

• gh workflow run: works, but check is not added to commit or PRs
• gh pr edit --add-label: workflow is not triggered when the label is created by GITHUB_TOKEN

Since Github will seemingly never listen to our requests, has anyone found an exploit to work around this, or has anyone tried any other designs to document what doesn't work?

[kehao95]

Github seems to be very thorough in not allowing us to re-run CI workflows:
gh workflow run: works, but check is not added to commit or PRs

i m having the same issue. In my use case, I want the workflow to amend commit and push -f. But once that done the check will never be triggered,

[bennobuilder]

As an alternative: If you want an action to run after another action, you can also use the repository_dispatch event to trigger the next action. For more information, check the GitHub documentation.

Example

1. First Workflow: .github/workflows/merge-develop-into-main.yml (Manual trigger, workflow_dispatch)

   name: Merge Develop into Main
   
   on:
     workflow_dispatch:
   
   jobs:
     merge:
       runs-on: ubuntu-latest
       steps:
         - name: Checkout
           uses: actions/checkout@v4
           with:
             token: ${{ secrets.GITHUB_TOKEN }}
         
         - name: Merge develop into main
           uses: actions/github-script@v7
           with:
             script: |
               github.rest.repos.merge({
                 owner: context.repo.owner,
                 repo: context.repo.repo,
                 base: 'main',
                 head: 'develop',
               });
         
         # <<<< HERE START
         - name: Trigger Publish Workflow
           uses: actions/github-script@v7
           with:
             script: |
               github.rest.repos.createDispatchEvent({
                 owner: context.repo.owner,
                 repo: context.repo.repo,
                 event_type: 'publish-trigger',
               });
         # <<<< HERE END

2. Second Workflow: .github/workflows/publish.yml (Triggered by "publish-trigger", repository_dispatch)

   name: Publish
   
   on:
     # <<<< HERE START
     repository_dispatch:
       types: [publish-trigger]
     # <<<< HERE END
   
   jobs:
     publish:
       runs-on: ubuntu-latest
       steps:
         - name: Checkout
           uses: actions/checkout@v4
           with:
             token: ${{ secrets.GITHUB_TOKEN }}
         
         # Add your publish steps here
         - name: Publish
           run: echo "Publishing..."

How I updated my actions

builder-group/community@a710dd2

[LecrisUT]

The issue is that the workflow does not show up on the commit. This is a particular issue for PRs

[bennobuilder]

But if the commit is triggered by you as the actual user it should work?

and if its triggered by an action you can make use of repository_dispatch by creating a dispatch event (e.g. As a step after your action that committed xyz)? Only if its a third party action that commits xyz if xyz it might get a bit more challenging to create a dispatch event at the right time.

[LecrisUT]

Look at your own repo:

• 208eaf61e93be4f4a50bef1e0a5a37526636aceb was triggered by push and the CI checks are displayed
• dbe5f5e20bb33f4048a0702db10eb28d7b79594f was triggered by workflow_dispatch so no CI check is attached to the commit

The key is to try and achieve the following:

• workflow_A: triggered by pull_request, creates a commit and then triggers workflow_B
• workflow_B: must appear in the PR checks

If you can achieve that with anithing repository_dispatch, wotkflow_dispatch, third-party service, nested Matryoshka dolls of actions, services or whatevers, you will have the eternal gratitude of the hundreds of us who are tired of this ridiculous restriction

[bennobuilder]

workflow_A: triggered by pull_request, creates a commit and then triggers workflow_B

This should be possible with the repository_dispatch approach. It's similar to my use-case:

I aimed to trigger the "Publish" action after manually triggering the "Initiate Publish" action.

• "Initiate Publish": Merges develop branch into the main branch. And as you know, merging branch x into branch y via GitHub Action doesn't trigger any action listening on on: push.
• "Publish": Publishes packages and some other stuff

And for that use-case the repository_dispatch approach seems to work:

Here, I'm triggering the "Initiate Publish" workflow:

And here's the "Initiate Publish" workflow triggering the "Publish" workflow via repository_dispatch:

workflow_B: must appear in the PR checks

I haven't tested whether the workflow appears in the PR checks 🤷

[LecrisUT]

And here's the "Initiate Publish" workflow triggering the "Publish" workflow via repository_dispatch

I saw that, and you can do it with workflow_dispatch as well. This is not the issue here.

I haven't tested whether the workflow appears in the PR checks 🤷

This is the main point, because if you have a CI with a required workflow that must pass, you will never be able to make it pass after you make a commit. An example is running pre-commit or check-dist which make trivial fixes or re-compilations, than these do not trigger the remaining tests of your workflow. A common occurrence is that you have dependabot or renovate bumping your dependencies, than you never get to fully test these updates until you manually rebase.

pre-commit-ci does work because it is run as an external service, and for some reason Github is ok with allowing that to re-trigger CI runs, but they will not allow the in-house actions to do so, even though you can have the exact same issues and safe-guards in both scenarios. Our only hope is a third-party service that we can trigger from a GH action to make a commit, and the only issue there is to host a publicly available server to do just this one small task.

[LecrisUT]

I have stumbled on peter-evans/create-pull-request. There there is a documentation on actual ways to workaround this frustrating issue. One approach there is using Github Apps and tibdex/github-app-token. It looks super promising. Wonder if a generic GH App could be created, probably as a manifest, or have a public one with hard-coded tibdex/github-app-token approach 🤔

Here is one example of that workflow in the wild 🙂

[kribor]

I don't consider this issue solved. Creating manual PATs for every repo is very tedious and not scalable. Surely a flag that overrides the default behavior to not trigger on_push workflows can't be unreasonably hard to add.