wp-git-cleanup.sh swallows git commit errors when .git/index.lock is stale

[khoipro]

Problem

When wp-git-cleanup.sh is interrupted mid-run (crash, timeout, killed shell), it leaves a stale .git/index.lock in the target webapp's repository. On subsequent runs, every git commit then fails with:

fatal: Unable to create '/home/runcloud/webapps/<site>/.git/index.lock': File exists.

But the script swallows the error and prints [OK] for every commit anyway. Result: the cleanup appears successful but no commits land. git status afterwards still shows everything modified.

Reproduction

1. Start wp-git-cleanup.sh --site=<frozen-site> --action=cleanup and crash it mid-run (Ctrl+C, OOM, etc.) so the lock file is left behind.
2. Run cleanup again — output looks identical to a successful run, ending in Done (cleanup).
3. git log --oneline -5 shows no new chore: commits.
4. git status shows the same modified/untracked files unchanged.

Observed on sg8/azpet-media (2026-05-01). The leftover lock was 2 MB; the retry printed 17 [OK] lines without committing anything.

Root cause

commit_files() (line 744 in wp-git-cleanup.sh) and a few other commit invocations swallow the exit code:

run_git "$owner" "$site_path" commit -m "$message" --quiet 2>/dev/null || true
success "  $message ($count files)"

2>/dev/null || true discards both stderr and the non-zero exit, then success() is called unconditionally. Same pattern at lines 293, 313, 718.

Fix

Two layers of defence:

1. Detect stale lock at start of cleanup — abort loudly if .git/index.lock exists. Recovery is explicit (rm -f .git/index.lock).
2. Check git commit / git add exit codes — emit warn/error and increment a failure counter when commits fail. Surface the count in the final summary.