Autofix workflow on a pull request invalidates previous check state without triggering new checks

I’ve got a workflow that runs on pull requests, to autofix formatting issues with prettier, and then commits + pushes the fixes (if any) back up to the pull-requesting branch.


yarn prettier

git commit -am "Committing autofixes"


echo "Pushing to repo..."
git merge FETCH_HEAD -m "Merging in remote"

This works great, but the resulting “Committing autofixes” commit doesn’t appear to trigger any checks. 

I guess this makes sense (to prevent actions that trigger themselves in an infinite loop), but the problem is that the pull request no longer thinks it has any checks – even if the previous checks had failed.

I’m “working around” this problem by, after autofixing happens, making an empty commit locally and pushing it up, e.g. git commit --allow-empty -m bump; git push, which triggers the checks again and brings things back to normal.

And then the pull-request looks like this:

Has anyone else run into this before? Is there a better workflow for having an action that commits autofixes back to a pull request?

I also tried closing & reopening the pull request after the autofix (which the docs claim will trigger a pull_request workflow), but it didn’t :confused:

Provided GITHUB_TOKEN is not allowed to trigger checks, you need to generate and use own/bot’s account/any other token and it will work just fine.

If using bot account to do formatting, you probably don’t want to waste time on formatting just-formatted code…

on: push
  runs-on: ubuntu-latest
  if: != 'my_bot_account'

…and works great to prevent infinite loop you mentioned.

1 Like