v1.8.8

Fixed

• The database restore could not sign in. It used the Seafile user with
  the root password; past that, it would have dropped seafiledb, a database
  that does not exist, instead of seafile_db. The application data restore
  cleared /seafile/, a path this stack does not have, then unpacked the
  archive over the live /shared, so files created after the backup
  survived it.
  Both scripts now take every path, name and credential from the running
  backups container, accept the backup file name as an argument, stop the
  application while they work and start it again whatever happens, and CI
  runs them: a marker written after a backup must be gone once that backup
  is restored, for the database and for the application data. The tests
  used to restore with their own copy of the commands, which is how the
  shipped scripts could drift while every run was green.

Changed

• The freshness check has its own workflow, Pin Freshness. It ran inside Deployment Verification, whose badge is the one at the top of this README. Across the fleet, nine red runs in ten were a pin one version behind - which the fleet's triage moves within the day - and a reader cannot tell that from a stack that does not boot. The badge now says whether the stack boots. The job itself is unchanged.

v1.8.7

Security

• traefik:3.7 was rebuilt upstream; the pin moved from sha256:1c32e7c36820… to sha256:24841fe2de73…. Same version, same tag, a rebuilt base image — the usual shape of a security fix in a base layer.

Upgrading

git pull (or ./update.sh), then docker compose up -d. Containers on a refreshed image are recreated; data volumes and .env are untouched. This release was cut by fleet triage after the deploy job booted the stack on the refreshed images.

Full history in CHANGELOG.md.

v1.8.6

Security

• redis:7.4 was rebuilt upstream; the pin moved from sha256:71da9275c5f3… to sha256:c6eabf748fc7…. Same version, same tag, a rebuilt base image — the usual shape of a security fix in a base layer.

Upgrading

git pull (or ./update.sh), then docker compose up -d. Containers on a refreshed image are recreated; data volumes and .env are untouched. This release was cut by fleet triage after the deploy job booted the stack on the refreshed images.

Full history in CHANGELOG.md.

v1.8.5

Changed

• seafileltd/seafile-mc:13.0.25 moved to seafileltd/seafile-mc:13.0.28. The freshness check reported the lag; the deploy job booted the stack on the new image before this landed.

Upgrading

git pull (or ./update.sh), then docker compose up -d. Containers on a refreshed image are recreated; data volumes and .env are untouched. This release was cut by fleet triage after the deploy job booted the stack on the refreshed images.

Full history in CHANGELOG.md.

What upstream changed

Read by fleet triage from the upstream release notes (or the commits between the tags) against this compose file, before the bump was applied.

Upstream changes 13.0.25 -> 13.0.28

Verdict: NEEDS ATTENTION — release notes for seafileltd/seafile-mc could not be retrieved (404), so this upgrade cannot be verified against upstream's own account of what changed; treat it as unreviewed until read by hand.

Breaking changes

• Not available. GitHub releases for seafileltd/seafile-mc returned HTTP 404. No notes were read, so none can be quoted, and none should be assumed either way.

Variables

• none confirmed — cannot be checked without the release notes. The compose file's own comment on the seafile service ("Seafile 12+ changed the container's environment contract: the MYSQL_*/SEAFILE_ADMIN-style variables from Seafile 11 are dead, the cache moved to Redis, and JWT_PRIVATE_KEY is required.") describes the 11→12 contract, already reflected in this compose file's environment block; nothing suggests a further variable change in 13.0.25→13.0.28, but this is not confirmed absence, only absence of evidence.

Data and dependencies

• Companion services pinned in this compose file: MariaDB 11.4, Redis 7.4. Since the seafile-mc release notes could not be read, there is no upstream statement confirming these versions are still the ones 13.0.28 expects. Per the standing rule, this alone is enough to withhold SAFE TO APPLY — the notes cannot be checked, so a mismatch cannot be ruled out.
• No migration or schema information available for this patch range (13.0.25 → 13.0.28 is a patch-level bump, which lowers but does not eliminate the chance of a required migration).

Before applying

• Read the actual upstream notes by hand before pulling: check the seafile-mc changelog/release page directly (the manual.seafile.com changelog, or the seafileltd/seafile-mc GitHub tags page under a different URL scheme than the one queried), and the project's own UPGRADING/CHANGELOG doc for the 13.0.25 → 13.0.28 range specifically.
• Confirm by hand whether 13.0.28 requires or recommends a MariaDB or Redis version other than 11.4 / 7.4.
• Take the routine backup before any Seafile upgrade regardless of notes availability — the backups service in this compose file already covers MariaDB dumps and data tar, confirm a recent one exists before proceeding.
• After reading the real notes, re-run this review; do not apply on the strength of "patch version, probably fine."

Notes read

• None. GitHub releases for seafileltd/seafile-mc could not be read: HTTP Error 404: Not Found, for both endpoints of the range (13.0.25 and 13.0.28). No UPGRADING/BREAKING_CHANGES/CHANGELOG section was supplied for this range either.

v1.8.4

Security

• traefik:3.7 was rebuilt upstream; the pin moved from sha256:f86a2cab1b5c… to sha256:1c32e7c36820…. Same version, same tag, a rebuilt base image — the usual shape of a security fix in a base layer.
• mariadb:11.4 was rebuilt upstream; the pin moved from sha256:65ad406b90f2… to sha256:70cc072b29b4…. Same version, same tag, a rebuilt base image — the usual shape of a security fix in a base layer.

Upgrading

git pull (or ./update.sh), then docker compose up -d. Containers on a refreshed image are recreated; data volumes and .env are untouched. This release was cut by fleet triage after the deploy job booted the stack on the refreshed images.

Full history in CHANGELOG.md.

v1.8.3

Security

• mariadb:11.4 was rebuilt upstream; the pin moved from sha256:80494b981069… to sha256:65ad406b90f2…. Same version, same tag, a rebuilt base image — the usual shape of a security fix in a base layer.

Upgrading

git pull (or ./update.sh), then docker compose up -d. Containers on a refreshed image are recreated; data volumes and .env are untouched. This release was cut by fleet triage after the deploy job booted the stack on the refreshed images.

Full history in CHANGELOG.md.

v1.8.2

A correctness fix to the backup loop, and it is worth reading even if the symptom never reached you.

The archive is read back before it is called a backup

The library tarball was renamed into place on tar's exit code alone. That code has never been a statement about whether the file it produced opens, and the gap is not theoretical: an archive truncated after tar had already exited still carries exit status 0. The old condition promoted it, logged Data backup OK, and pruned older archives around it.

Measured in the image this sidecar actually runs, rather than argued from the manual:

case	tar's exit code	old condition	with the read-back
a good archive	0	promoted	promoted
destination blocked by a directory	2	refused	refused
archive truncated after tar exited	0	promoted	refused

One tar -tzf between the write and the rename now decides it.

What is deliberately not changed

The database dump. It is written as pg_dump \| gzip > f.partial under set -o pipefail, where a failure at either end of the pipe — including a full disk — already fails the pipeline and nothing is renamed. Adding gzip -t there would be noise, not safety.

How it was found

A rule was added to fleet-ops asserting this property across every repository, after one loop turned out to be missing it. Eighteen were, all with the same shape, all fixed in the same batch.

Upgrading

./update.sh

No variables changed, no data touched, no manual step.

v1.8.1

Security

• mariadb:11.4 was rebuilt upstream; the pin moved from sha256:611a2fcc5fa7… to sha256:80494b981069…. Same version, same tag, a rebuilt base image — the usual shape of a security fix in a base layer.

Upgrading

git pull (or ./update.sh), then docker compose up -d. Containers on a refreshed image are recreated; data volumes and .env are untouched. This release was cut by fleet triage after the deploy job booted the stack on the refreshed images.

Full history in CHANGELOG.md.

v1.8.0

Added

• update.sh: move between release tags on purpose. It updates to the latest release (a combination this repository's CI has booted and smoke-tested), refuses to cross a major version unattended, refuses to run over local changes, and names any new required variable before anything has moved. --dry-run says what would happen.

Upgrading

git pull (or ./update.sh). Nothing running changes: this release adds or extends the update script and touches no image pin.

Full history in CHANGELOG.md.

v1.7.0

Fixed

• A backup interrupted halfway no longer looks like a good one. The loop
  already renamed a failed dump to .failed so nothing would restore from it,
  but that rename only runs if the shell lives long enough to reach it. Stop
  the container mid-dump and it does not: the truncated file keeps the name a
  finished backup would have, and it is the newest one, which is exactly what
  the restore script and the end-to-end test pick. Every backup is now written
  to <name>.partial and renamed only after the dump succeeds, so the real
  name never exists unless the file behind it is complete. Verified by killing
  a dump in flight: before, the restore path selected a file that failed
  gzip -t; after, it finds nothing to select.