Push from Action does not trigger subsequent action · community · Discussion #25702 (original) (raw)

You must be logged in to vote

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}}

View full answer

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}}

You must be logged in to vote

7 replies

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 }}

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.

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

If you can't declare persist-credentials: false for whatever reason and don't want to hand your secret to a third-party action, here's how to clear the persisted credentials and override them just for the git push:

  name: Push
  env:
    GH_TOKEN: ${{ secrets.YOUR_TOKEN }}
  run: |
    git config --global user.name 'github-actions'
    git config --global user.email 'github-actions@users.noreply.github.com'
    
    git add <YOUR FILES>
    git commit -m "[github-actions] <YOUR MESSAGE>"
    
    # Clear any cached credentials and configure git to use our PAT
    # The default GITHUB_TOKEN does not trigger CI workflows, so we must use the PAT
    git config --unset-all http.https://github.com/.extraheader || true
    git config --global --unset-all credential.helper || true
    git config --local --unset-all credential.helper || true
    
    # Push with PAT in URL
    git push "https://x-access-token:${GH_TOKEN}@github.com/${{ github.repository }}.git" HEAD:${{ github.ref_name }}

PAT tokens are prohibited by our org policy. This is very unfortunate limitation.

You must be logged in to vote

0 replies

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

You must be logged in to vote

0 replies

You must be logged in to vote

0 replies

You must be logged in to vote

0 replies

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

You must be logged in to vote

0 replies

it took me hours to find this post.

You must be logged in to vote

0 replies

You must be logged in to vote

2 replies

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

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.

You must be logged in to vote

0 replies

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".

You must be logged in to vote

0 replies

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.

You must be logged in to vote

0 replies

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

You must be logged in to vote

0 replies

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

You must be logged in to vote

0 replies

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

You must be logged in to vote

4 replies

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

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

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?

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,

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

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
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

You must be logged in to vote

5 replies

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

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.

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

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 🤷

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.

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 🙂

You must be logged in to vote

0 replies

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.

You must be logged in to vote

0 replies

You must be logged in to vote

0 replies

It worked after using a PAT in the checkout action (v3)

You must be logged in to vote

0 replies

I bet they are trying to avoid infinite loops in actions, still it's a very unexpected behavior.

You must be logged in to vote

0 replies

The year is 2026 and here is still no option to work this around...
How about adding something like a permission for this (instead of Copilot integrations everywhere)?

Btw the "workaround" of using a (personal) access token is working out really great:
A developer now has to give a (bot) account write access to the entire repository and that account can definitely never be compromised.

So we as developers are now forced to design a insecure system to make this work. Great!

You must be logged in to vote

0 replies