stefanzweifel/git-auto-commit "nothing to commit, working tree clean"

By Kaveh Alemi·Latchkey

git-auto-commit only commits when there are staged changes. If the prior step produced no diff, the action reports a clean tree and makes no commit, which downstream steps may misread as a failure.

What this error means

The git-auto-commit step logs "nothing to commit, working tree clean" and no commit is pushed.

nothing to commit, working tree clean
Working tree clean. Nothing to commit.

Diagnose it: is the job queued, or is the runner gone?

A job that never starts and a job whose runner disappeared mid-run look similar in the UI and have opposite causes. The first is a labelling or capacity problem, the second is the runner being killed, usually by memory pressure or a spot reclaim.

- name: Runner facts
  run: |
    echo "runner name: $RUNNER_NAME"
    echo "os/arch:     $RUNNER_OS/$RUNNER_ARCH"
    nproc; free -h; df -h /
    echo "labels this job asked for: ${{ toJSON(job) }}"

Common causes

Generator produced no change

The formatter, codegen, or build step output bytes identical to what is already committed.

Files outside the configured glob

Changes landed in paths not matched by file_pattern, so the action sees nothing to stage.

How to fix it

Treat a clean tree as success, and check the file pattern

1. Confirm the file_pattern matches the paths your step writes.
2. Read the changes_detected output instead of failing on the clean-tree message.
3. Gate follow-up steps on changes_detected == true.

- id: commit
  uses: stefanzweifel/git-auto-commit-action@v5
  with:
    file_pattern: 'src/**/*.ts'
- if: ${{ steps.commit.outputs.changes_detected == 'true' }}
  run: echo "committed"

The failures that are not your workflow

• Exit 137 is the kernel out-of-memory killer, not an application error. Check free -h above against your peak usage.
• Disk exhaustion presents as unrelated write errors deep in a build. GitHub-hosted runners ship roughly 14 GB of free space, which a Docker-heavy job can exhaust.
• A lost connection to the server on a self-hosted runner is usually the host being reclaimed or rebooted, not a network fault in your job.
• A job that starts and immediately fails with no step output normally failed during runner setup, before your workflow ran at all.

How to prevent it

• Gate downstream steps on the changes_detected output.
• Set file_pattern to exactly the paths your generator writes.

Frequently asked questions

Related guides

References

• GitHub Actions documentation
• Workflow syntax for GitHub Actions