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

```yaml
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:

```bash
# 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*