Does this work?

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

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,

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.