feat: add commit input to control snapshot behavior

[devin-ai-integration]

Summary

Adds a commit input to avoid redundant Ceph snapshots when multiple parallel jobs mount the same sticky disk key.

Problem: When N parallel shards mount the same key (e.g. 16 test runners reading a shared build artifact), every shard commits an identical snapshot at job end, causing N× storage usage.

New commit input (default "true", backward compatible):

Value	Behavior
true	Always commit (existing behavior)
false	Never commit (mount is read-only, post step calls cleanupStickyDiskWithoutCommit)
if-missing	Only commit if the disk was freshly formatted at mount time (no prior snapshot existed). Skips commit on cache hits. First-writer-wins semantics.
on-change	Commit only if df used-bytes changed by more than 4KB since mount

How it works: maybeFormatBlockDevice now returns wasFormatted: boolean. When blkid finds existing ext4, wasFormatted=false (cache hit); when the device needs mkfs.ext4, wasFormatted=true (cache miss). This is saved to state as STICKYDISK_WAS_FORMATTED and checked by the if-missing mode in the post step.

Usage for the parallel-shard case:

# Build job writes artifacts, commits on first run only
- uses: useblacksmith/stickydisk@v1
  with:
    key: test-backend-${{ github.sha }}-artifact
    path: ./artifacts
    commit: "if-missing"

# Test shards read-only, never commit
- uses: useblacksmith/stickydisk@v1
  with:
    key: test-backend-${{ github.sha }}-artifact
    path: ./artifacts
    commit: "false"

Limitation: If all runners start simultaneously before any snapshot exists, they all get fresh disks (wasFormatted=true) and all commit. True first-writer-wins atomicity for that race would require a server-side change to commitStickyDisk.

Link to Devin session: https://app.devin.ai/sessions/787e1e5841d4400e9d6d18ffc5e81015

---

^{Need help on this PR? Tag @codesmith with what you need. Autofix is disabled. (Staging)}

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 27e0cc7. Configure here.}

[cursor]

On-change skips real file changes

Medium Severity

on-change decides whether to snapshot by comparing df used-byte totals within a 4KB band, but many real updates (same-size overwrites, delete-plus-add with similar footprint, metadata-only churn) leave used space flat, so the post step skips commit while file contents differ from the mounted baseline.

Additional Locations (1)

• action.yml#L14-L15

 

^{Reviewed by Cursor Bugbot for commit 27e0cc7. Configure here.}

[devin-ai-integration]

Acknowledged — the df-based heuristic is intentionally coarse for this use case. The primary target is read-only consumers (e.g., 16 test shards that mount a shared build artifact and never write to it), where used-bytes will be exactly unchanged.

For the pathological edge case (same-size overwrite, balanced delete+add), users should use commit: "true" (the default) or commit: "false" for explicit control. The on-change mode is a best-effort optimization for the common "mount, read, done" pattern — not a content-addressable guarantee.

A block-device write I/O counter (/sys/block/*/stat field 5) would be more precise, but it's harder to reliably map mount→device at setup time (before findmnt shows it), and any I/O at all (even a stray atime update or journal replay) would trigger a commit, reducing the dedup benefit.

[linear-code]

BLA-4031