3 Commits

Include renames

Author	SHA1	Message	Date
Emma ThorpeandClaude Opus 5	6df53d7c42	build: publish amd64 only ... The NAS is the only host this container runs on. Building linux/arm64 as well meant emulating it under QEMU on every release for a consumer that does not exist, so both the second platform and the QEMU setup step are dropped. Nothing in the image is architecture-specific; restoring arm64 is a one-line change if it ever gains a home on the Pi. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-21 15:25:44 +01:00
Emma ThorpeandClaude Opus 5	cbcbf30228	build: drop the Nix packaging and test inside the container ... The deployment target is a container on TrueNAS Scale, so the flake sat on no path between the source and the NAS. It was carried over from a sibling project where the flake is the deployment mechanism; here it only added a second build path and a second dependency pin. Worse, it tested the wrong thing: `nix flake check` ran the suite against nixpkgs' ffmpeg while the shipped artefact contains Debian's, and encoder and muxer behaviour is exactly what these tests cover. The Dockerfile gains a `test` stage that installs pytest and runs the suite against the image's own ffmpeg; a failing test fails the build. CI runs `docker build --target test` in place of the host-based Python setup, and the push build states `target: runtime` so the published image is the lean stage rather than the last one in the file. The runtime image carries neither the tests nor pytest. The release step now calls python3 rather than python, since setup-python is no longer in the job to provide the alias. Removes package.nix, flake.nix and flake.lock. A dev shell is a `nix shell` away for anyone who wants one, and the README says so. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-21 15:06:06 +01:00
Emma ThorpeandClaude Opus 5	82c9da6d62	ci: publish the container image to the Gitea registry ... Adopts the release scheme from legacy-email-proxy so both repositories behave the same way: the version is derived from conventional commits since the last v* tag, the image is pushed under the full version, the truncated major.minor and major forms, and latest, and non-release builds are published as sha-<short>. Multi-arch (amd64 for the NAS, arm64 so the same image runs on a Pi). Authentication uses the PACKAGES_SECRET repository secret. The release step also writes the computed version into pyproject.toml and commits it as chore(release) before tagging, so the packaging metadata cannot drift behind the release. It skips the commit when the file already carries that version, which would otherwise fail the job after the image had been pushed. compose.yaml and the README now reference the published image instead of instructing the NAS to build one locally. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-21 14:44:29 +01:00