fix: support Docker v26 on Ubuntu 26

[alvins82]

Summary

• upgrade Docker and Compose dependencies for current daemon APIs
• migrate Docker v26 and compose-go v2 types across services, routes, and validation
• retain client API negotiation and add regression coverage for API 1.44
• add a real Compose lifecycle integration test
• build appfile2compose per target architecture and safely retire only CasaOS's legacy daemon override

Root cause

The previous Docker SDK capped its client API at 1.43 and used compose-go v1 types. Current Docker releases on Ubuntu 26 reject that obsolete client path, while the installer workaround lowered the daemon minimum API instead of updating AppManagement.

Impact

AppManagement now negotiates normally with current Docker releases while retaining compatibility with Docker 24. The package version is bumped to v0.4.17, and migration removes the exact CasaOS-managed override without overwriting administrator customizations.

Validation

• go generate ./... and go mod tidy with Go 1.21.13
• full go test -race -v ./... -timeout 30m on Linux with real Docker
• API negotiation regression test against a fake API 1.44 daemon
• real create/start/stop/remove Compose lifecycle on Docker 24.0.9 (API 1.43) and Docker 29.7.2 (API 1.55)
• GoReleaser snapshot with native ELF artifacts for amd64, arm64, arm/v7, and riscv64
• fresh install, upgrade, reboot, UI, catalog, and Compose lifecycle on Ubuntu 26.04 arm64

Release ordering

Release AppManagement v0.4.17 before merging the installer PR that pins this version.

[sonarqubecloud]

Quality Gate passed

Issues
24 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.9% Duplication on New Code

See analysis details on SonarQube Cloud

[inkly]

Hi @alvins82 — I found your fork while looking at where CasaOS stands after upstream went quiet, and I've been going through it locally. It's the most serious continuation I've seen: real multi-arch releases, a proper changelog, and actual test coverage, which upstream never had.

One concrete thing from the review: TestAreAllMergesMounted in CasaOS-LocalStorage (added in 9225bec) panics in a clean environment:

panic: attempt to write a readonly database (1032)
  pkg/sqlite.GetDBByFile -> db.AutoMigrate
  service/v2/merge_test.go:141

The DSN file::memory:mergeall?cache=shared is mattn/go-sqlite3 syntax, but the project uses glebarez/sqlite (pure-Go modernc), which reads it as a filename. Changing it to file:mergeall?mode=memory&cache=shared makes the whole suite pass — verified in golang:1.23 on Linux.

It slipped through because nothing runs go test on the forks: the only workflows are the ones inherited from upstream, and "Demo Reset" has been failing since 25 Aug because it needs IceWhale's AWS secrets.

Happy to send that as a PR, together with a small workflow that runs build+test on push/PR. Issues are disabled on all your forks (GitHub's default, easy to miss) so there's currently no way for anyone to report anything.

Longer term: I'm evaluating whether to put maintenance time into CasaOS, and I'd rather help an existing fork than start a 2195th one. If you're open to co-maintainers, I'm interested — if you'd rather keep it solo, no problem, the test fix stands either way.

[inkly]

Correction to my previous comment — I got one thing wrong, and the actual finding is different from what I described.

Wrong: I said nothing runs go test on the forks. It does — "Collect Code Coverage" runs on every push and PR on both CasaOS and CasaOS-LocalStorage and passes, including on 9225bec. I'd only looked at the run history of CasaOS, where "Demo Reset" fills the recent pages, and generalised from it. My mistake.

The actual issue: the test passes, but it isn't testing what it appears to. glebarez/sqlite (pure-Go modernc) doesn't accept the mattn/go-sqlite3 file::memory: syntax, so GetDBByFile("file::memory:mergeall?cache=shared") opens an on-disk database. On a clean Linux container:

$ go test ./service/v2/ -run TestAreAllMergesMounted
ok   .../service/v2  0.038s

$ ls service/v2/
-rw-r--r-- 1 root root 20480 ':memory:mergeall'

So: a stray SQLite file is written into the source tree on every run and isn't gitignored; the test isn't isolated, since rows accumulate across runs on the same machine; and it hard-fails with attempt to write a readonly database on any filesystem that rejects : in filenames — which is how I hit it, running the suite over a Windows bind mount.

file:mergeall?mode=memory&cache=shared is what this driver expects — suite stays green, no file created.

The CI half of my offer was unnecessary, sorry for the noise.

[alvins82]

Hi @alvins82 — I found your fork while looking at where CasaOS stands after upstream went quiet, and I've been going through it locally. It's the most serious continuation I've seen: real multi-arch releases, a proper changelog, and actual test coverage, which upstream never had.
...
Longer term: I'm evaluating whether to put maintenance time into CasaOS, and I'd rather help an existing fork than start a 2195th one. If you're open to co-maintainers, I'm interested — if you'd rather keep it solo, no problem, the test fix stands either way.

Hey @inkly happy to take PRs etc.