GitHub Actions workflow not triggering after force push (paths filter gotcha)

Not a native English speaker — corrections welcome!

The symptom

I was setting up an auto-publish pipeline for this blog: push a markdown file to posts/, and a GitHub Action publishes it to Hashnode. The workflow triggers like this:

on:
  push:
    branches: [main]
    paths:
      - "posts/**"

I force-pushed a commit that definitely changed files under posts/. Then... nothing.

No workflow run. Not a failed run. Not a skipped run. gh run list showed nothing for that commit, and the Actions tab was empty too.

I checked the usual suspects:

• Actions enabled for the repo — yes
• Workflow file state active — yes
• main actually pointing at my new commit — yes

Everything looked correct. Still silence. This was the confusing part: a failed run gives you a log to read. No run gives you nothing.

The cause

The force push was the problem — combined with the paths filter.

I was consolidating two repositories, so my force push replaced main with a completely unrelated history (no common ancestor between the old and new commits).

To apply a paths filter, GitHub has to answer "which files changed in this push?" by diffing the before/after commits. My best understanding: when the push is a force push to an unrelated history, that diff can't be computed in a meaningful way — and in my case, GitHub silently skipped the workflow instead of running it.

(The docs say that with very large pushes or diff timeouts the workflow "always runs", which is the opposite behavior — so the unrelated-history case seems to be its own thing. If you know the exact rule, please correct me in the comments.)

The fix

One normal commit that touches a path matching the filter:

# any real change under posts/ works
echo "" >> posts/my-post.md
git add posts/my-post.md
git commit -m "Kick CI after force push"
git push origin main

This triggered the workflow immediately, because now GitHub can diff against the previous commit like normal.

Two details that matter:

• git commit --allow-empty does not work here. An empty commit changes no files, so the paths filter matches nothing.
• The kick commit must touch a file that matches your filter (posts/** in my case).

What I learned

• Avoid force-pushing to a branch that has paths-filtered workflows.
• If you must force-push, follow it with a normal commit touching a filtered path to "restart" the trigger.
• When a push produces no run at all (not even a failed one), suspect the trigger filters before suspecting the workflow itself.

---

Keywords for fellow searchers: github actions workflow not running after force push · on push paths not triggering · workflow silently skipped · no workflow run created after push