elway: upload with content-hash idempotency (like ansible.copy) #6

New Issue

2026-04-24T10:40:44-07:00

vh commented

2026-04-24 10:40:44 -07:00

Today upload: steps always report changed after a successful scp+chmod. Ansible's copy module compares local+remote sha256 and reports unchanged when they match. Would turn upload into a first-class idempotent operation.

Proposal

Before scp:

Compute sha256 of local file.
ssh sha256sum <dest> 2>/dev/null — capture remote hash.
If hashes match, skip scp, skip chmod (unless mode also needs changing — check remote stat, then skip).
Report ok (the file was already the desired content) rather than changed.

Existing creates: already covers "skip if path exists", but that's coarse — doesn't re-upload on content change. Hash check is the proper semantic.

Edge cases

mode: on a file that already has correct content but wrong perms — should report changed (perm did change) even though bytes didn't.
Remote hash command: sha256sum is coreutils, present on every Debian/Ubuntu, but worth degrading to shasum -a 256 or openssl dgst -sha256 if the first fails.
Sudo uploads go through /tmp staging — can hash before mv, skip entire mv+chmod if hash matches.

LOE

~40-60 LOC. Lives inside run_upload_step plus one helper.

Why file separately

For bytes-on-disk workloads this would eliminate spurious "changed" on re-runs of upload-heavy playbooks (every deploy currently shows as changed even when nothing moved). But it requires consistent hash tooling on every remote, which is fine for Linux hosts but worth documenting.

Today `upload:` steps always report `changed` after a successful scp+chmod. Ansible's `copy` module compares local+remote sha256 and reports unchanged when they match. Would turn upload into a first-class idempotent operation. ### Proposal Before scp: 1. Compute sha256 of local file. 2. ssh `sha256sum <dest> 2>/dev/null` — capture remote hash. 3. If hashes match, skip scp, skip chmod (unless mode also needs changing — check remote stat, then skip). 4. Report `ok` (the file was already the desired content) rather than `changed`. Existing `creates:` already covers "skip if path exists", but that's coarse — doesn't re-upload on content change. Hash check is the proper semantic. ### Edge cases - `mode:` on a file that already has correct content but wrong perms — should report `changed` (perm did change) even though bytes didn't. - Remote hash command: sha256sum is coreutils, present on every Debian/Ubuntu, but worth degrading to `shasum -a 256` or `openssl dgst -sha256` if the first fails. - Sudo uploads go through /tmp staging — can hash before mv, skip entire mv+chmod if hash matches. ### LOE ~40-60 LOC. Lives inside `run_upload_step` plus one helper. ### Why file separately For bytes-on-disk workloads this would eliminate spurious "changed" on re-runs of upload-heavy playbooks (every deploy currently shows as `changed` even when nothing moved). But it requires consistent hash tooling on every remote, which is fine for Linux hosts but worth documenting.

vh added the enhancement label 2026-04-24 10:40:44 -07:00

vh referenced this issue from a commit

2026-08-19 21:40:26 -07:00

feat(waterland-studio): deploy b72425b — all three upstream findings fixed

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: vh/esh-pfi-infrastructure#6