[oleksandr-nc]

Problem

The published release image was last built in April 2026 and its system CA store (ca-certificates 20230311+deb12u1) predates several public roots. nc_py_api verifies TLS against the system store, not certifi, so the init status report to Nextcloud fails with CERTIFICATE_VERIFY_FAILED when the instance certificate chains to one of those newer roots. Test Deploy then fails at the init step although the setup itself is fine.

The CI workflow was also red, for an unrelated reason: it enabled app_api from the app store, which resolves to the old 3.2.3 release. That version calls DIContainer::query(), which is protected on server master now, so the init status request ended in a PHP fatal.

Changes

• Base image: python:3.12-slim-bookworm -> python:3.14-slim-trixie (Debian 13, ca-certificates 20250419), for both build stages.
• torch: 2.8.0 -> 2.9.1. 2.8.0 has no Python 3.14 wheels. 2.9.1 has them for CPU, CUDA, ROCm and arm64, and it still uses CUDA 12.8 and the rocm6.4 index, so host GPU driver requirements stay the same. Later torch releases move to ROCm 7.x and newer CUDA packaging.
• CI: check out AppAPI main instead of enabling the app store release.
• CI: build the CPU image from the checkout and deploy that one (registry mapping ghcr.io -> local on the daemon), so Dockerfile changes are exercised before a release. Until now the workflow deployed the published image. The log check now names the assertion that failed.

Testing

• CI deploys the image built from this branch: the container log shows pytorch package version: 2.9.1+cpu and all log assertions pass.
• Locally, CPU variant: Python 3.14.7, Debian 13, torch 2.9.1+cpu, torchvision 0.24.1+cpu, nc_py_api 0.30.3; frpc, curl, nc, ping, ps present.
• An HTTPS request with niquests to a site whose chain ends in a root missing from the old image fails on the current release image and succeeds on the new one.
• Full deploy through a HaRP Docker daemon (FRP tunnel): all CI log assertions pass, plus frpc start proxy success.
• Full deploy through a HaRP Kubernetes daemon (kind, ClusterIP): deploy, init and enable pass.

The CUDA and ROCm variants were not built; the torch 2.9.1 and torchvision 0.24.1 cp314 wheels exist on PyPI and on the rocm6.4 index.

After merge the three publish workflows need a manual run to refresh release, release-cuda and release-rocm.