admin/felhom-controller
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

v0.82.0: gate FileBrowser recreate on actual change (F2); drop unused restic binary (F1)

Browse Source 
syncFileBrowserMounts no longer force-recreates FileBrowser unconditionally:
captures config.yaml+compose before writes, re-reads final content after, and
recreates only when they actually changed (new pure helper fbNeedsRecreate).
Controller restarts / no-op storage syncs now issue a plain up -d and do NOT
bounce the customer's file UI. Restore-mode DB reset still forces a recreate.

Dockerfile: removed the unused restic apt package (disk-tier restic moved to the
host agent; no controller code execs the binary). ResticSchedule/migrateResticToRsync
config+settings paths untouched (still live in the dashboard).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FpBYrZCt9sFDqLgbG5GRGD
This commit is contained in:
authentik Default Admin
2026-06-24 11:01:18 +02:00
parent 036a6078bb
commit 9cd566ded7
6 changed files with 123 additions and 74 deletions
Download Patch File Download Diff File Expand all files Collapse all files
CHANGELOG.md
+19
View File
@@ -1,5 +1,24 @@
## Changelog
### v0.82.0 — FileBrowser sync no longer bounces the file UI on no-op; drop dead restic binary (2026-06-24)
- **F2 — gate the FileBrowser recreate on an actual change.** `syncFileBrowserMounts` (`internal/web/handlers.go`)
previously ran `docker compose up -d --force-recreate --remove-orphans` **unconditionally**, so every
controller restart and every storage sync force-recreated the FileBrowser container even when its
`config.yaml`/compose were byte-identical — bouncing the customer's file-access UI and contradicting the
"Vezérlő újraindítása → apps keep running" promise. Now it captures the on-disk `config.yaml`+compose
**before** the writes and re-reads the **final** content **after** them (so the integrations'
`ReapplyConfigForTarget` edits are included), and recreates only when something actually changed via the
new pure helper `fbNeedsRecreate(oldCfg,newCfg,oldCompose,newCompose)`; otherwise a plain `up -d` ensures
it's running without a bounce. The restore-mode DB reset (`sourcesChanged && resetDBOnChange` → `down -v`)
is preserved and forces `changed=true` (a reset removes the container). First-ever run (empty old files)
still recreates. Unit-tested (`filebrowser_gate_test.go` `TestFbNeedsRecreate`, incl. red-proof against the
old unconditional behaviour).
- **F1 — dropped the unused `restic` binary from the image** (`controller/Dockerfile`). The disk-tier restic
work moved to the host agent; no controller code execs the binary (the only `"restic"` references are a
backup-dir-name comparison and the `Method` config string, both unaffected). Removed the `restic` apt line
and its comment. The `ResticSchedule`/`migrateResticToRsync` config+settings paths are **untouched** (still
live in the dashboard).
### v0.81.0 — retire the drive-activation banner; add a standalone "Kiszolgáló újraindítása" button (2026-06-23)
- **Removed the obsolete drive-activation banner.** In the intermediary-mount model an enrolled drive
binds **live** into the running guest (agent `disks.go` — no `pct set -mpN`, no slot, no reboot), so