SisyphusMD/archiver
Watch
0
0
Fork
You've already forked archiver
 0
Code Issues 1 Pull requests 5 Releases 43 Packages 1 Activity Actions
43 releases 43 tags
  • v0.10.3 8a25cfb9cc

    v0.10.3
    Some checks failed
    CI / Build / Publish / Shellcheck (push) Successful in 4s
    Details
    CI / Build / Publish / Validate CHANGELOG structure (push) Successful in 2s
    Details
    CI / Build / Publish / Bats unit tests (push) Successful in 10s
    Details
    CI / Build / Publish / PR build & smoke test (push) Has been skipped
    Details
    CI / Build / Publish / Host-driven integration (entrypoint + storage sidecars) (push) Successful in 2m52s
    Details
    CI / Build / Publish / Round-trip + scheduler smoke (push) Successful in 4m14s
    Details
    CI / Build / Publish / Build multi-arch and push (push) Successful in 4m7s
    Details
    CI / Build / Publish / Reconcile releases across registries (push) Successful in 1m49s
    Details
    CI / Build / Publish / Workflow summary (push) Failing after 3s
    Details
    Stable

    Cody Bryant released this 2026-07-23 18:15:17 -07:00 | 38 commits to main since this release

    Fixed

    • The recovery-kit permissions change in 0.10.2 only took effect on local storage targets; on SFTP targets the kit was still placed with the connecting user's umask, so where that user's umask is restrictive (e.g. server with 077) the kit landed owner-only and a separate mirror/backup user still could not read it — the very outlier 0.10.2 set out to eliminate. The SFTP upload now reads the mode of the storage's own config file and applies it to the kit and its README with a best-effort chmod after upload (a server that forbids SETSTAT still yields a successful upload), matching what the local path already does. The placement-scheme version is bumped again, so existing deployments re-stamp their already-placed kit once on the first backup (or archiver recovery-kit) run after upgrade — no recovery-kit force needed.
    Downloads