Running python3 -m venv venv over an existing cached venv recreates
the absolute symlinks and pyvenv.cfg paths so Python resolves to
the current system's python3 binary. Without this, cp -a preserves
stale symlinks from the cache source, causing venv/bin/python to
resolve to /usr/bin/python3 (system, not venv) and pytest not found.
Also switch validation to use python3 to match Ubuntu 24.04 convention.
Ubuntu-latest runner containers on NAS dont have the gitea_gitea network, so http://gitea:3000 is unreachable. Use 172.21.0.1:3300 (Docker bridge gateway) instead.
Add build-image-dev job (runs-on: vps) - builds with Podman on server2,
pipes the finished image to NAS via SSH, retags from localhost/ prefix.
Deploy job now depends on build-image-dev instead of backend-tests.
NAS HDD I/O was the bottleneck for Docker builds. VPS has SSD and
matches NAS x86_64 architecture perfectly.
The CI container may not have /volume1/docker/claude-dev/.env mounted,
causing 'docker compose config' to fail.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Venv symlinks break when cache is used across different environments
(VPS host vs NAS Docker). python -m pytest is resilient because it
loads pytest as a module, not via a shebang-based script.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
host.docker.internal not resolving in act containers on Synology Docker.
The gateway IP 172.21.0.1 routes to the host where Gitea is now
bound to 0.0.0.0:3300.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Use host.docker.internal:3300 with ubuntu-latest runner.
Gitea port now bound to 0.0.0.0:3300 so Docker containers
can reach it.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Changed Gitea HTTP port binding from 127.0.0.1:3300 to 0.0.0.0:3300
so Docker containers can reach Gitea via host.docker.internal.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Docker volume mounts may not auto-create mount points inside the
job container. Use mkdir -p to ensure the target directory exists
before copying files.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The act Docker containers on the NAS runner cannot reach Gitea
on the gitea_gitea network despite the runner config. Switching
to the 'nas' runner label which uses host mode — jobs run directly
on the NAS host where localhost:3300 reaches Gitea.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Replaces 'gitea:3000' with '172.21.0.4:3000' to bypass DNS
resolution issues in act job containers. Also removed --dns
override from runner-config.yaml which was breaking Docker's
embedded DNS and container name resolution.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The cached venv's python binary may work but tool symlinks (pytest, etc.)
break when restored in a different environment. Test pytest specifically
to catch this.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Cached venvs from NAS Docker containers have broken symlinks when
restored on the VPS host, causing "pytest: command not found".
Add a functional check that venv/bin/python runs before accepting
the cache as valid.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Backend and frontend tests now run on `runs-on: vps` (server2 at
158.101.140.85, host mode) with checkout via Tailscale IP. Deploy
job stays on `runs-on: nas` with gitea_gitea network for Docker
socket access. This eliminates the HDD bottleneck and Docker
network/DNS issues that plagued the all-NAS pipeline.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Job containers were created on isolated bridge networks that couldn't
reach Gitea at any address. Add workflow-level container blocks to
backend-tests and frontend-tests (matching deploy job) so all job
containers are on the gitea network and can resolve "gitea" via
Docker's embedded DNS. Revert checkout URLs back to gitea:3000.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
host.docker.internal doesn't resolve in job containers despite the
runner config setting --add-host. Use the NAS LAN IP directly,
which is reachable from any Docker bridge network.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Job containers are on their own bridge networks and can't reach
172.21.0.4 (Gitea's IP on gitea_gitea network). Use the Docker host
gateway with port 3300 (which maps to Gitea container's 3000) instead.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Runner's --dns options bypass Docker's embedded DNS resolver, so job
containers can't resolve the "gitea" hostname even when connected to the
gitea_gitea network. Add /etc/hosts entry pointing gitea to 172.21.0.4
before each checkout step.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Cold venv installs on the NAS HDD exceed 300s, causing the backend
tests install step to be killed by timeout. Double the timeout so the
first or fallback pip mirror attempt can complete before the timeout
fires.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Bypass Docker 24 network connection bug during compose container creation by stripping network settings and connecting networks manually.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The container takes ~183s to become healthy on the slow NAS HDD.
90 iterations at 2s (180s) kept timing out by ~3 seconds.
Increased to 120 iterations (240s) for safety margin.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The NAS HDD is slow enough that container startup can exceed 60
seconds. The app was starting successfully (Uvicorn running) but
the health check timed out just before the container became healthy.
Increased to 90 iterations at 2s = 180s max wait.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The ${GITEA_DB_PASSWORD} syntax in the workflow YAML expands to empty
because Gitea Actions doesn't pass workflow-level env vars to themselves.
Using the actual password value directly.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The dashboard OPC module connects to the Gitea PostgreSQL database
but the deploy.yml workflow and docker run fallback were missing the
GITEA_DB_PASSWORD env var, causing the container to crash on startup
with password authentication failures.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Old nas-dashboard from failed runs was still running, causing the
retry path to skip (old container detected as running). Also stale
docker-socket-proxy with restart:unless-stopped caused compose
conflict. Fix by force-removing both before compose.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Container crashed with RuntimeError: TRANSMISSION_USER and
TRANSMISSION_PASS must be set. Add all env vars from compose file
including SSH, Transmission, WebAuthn, and volume mounts. Also
add NETWORKS=1 to docker-socket-proxy for compose network support.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The network stripping Python script had bugs causing dashboard service
to be omitted. Replace with simpler approach: remove stale containers
and retry compose, with docker run as final fallback.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
When docker compose --pull never fails due to network endpoint issues,
the retry with stripped networks fails because docker-socket-proxy
container already exists (restart: unless-stopped recreates it after
compose down). Fix by force-removing it before the retry.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Gitea 1.26.2 reports job conclusion=failure even when all steps succeed,
causing the deploy job (with needs:) to be skipped. Two fixes:
- Add if: always() to deploy job so it runs regardless of test job conclusions
- Fix concurrency: YAML structure (was nested under on: instead of top-level)
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The docker socket was mounted twice (runner + deploy.yml), causing
"Duplicate mount point: /var/run/docker.sock" errors. Also removed
invalid docker-compose plugin path that doesn't exist on the runner.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
- Add :-admin defaults for TRANSMISSION_USER/PASS in docker-compose.yml
to prevent crash on startup when vars are unset
- Add --max-time 10 to registry mirror health check curl to prevent
2+ minute hang when mirror is unreachable
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
- Add docker compose down step before up to ensure the production
container is recreated with the freshly-built image
- Without this, compose sees the old running container and skips it,
while the Docker 24 network bug is silently swallowed by || true
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
- Add SECRET_KEY env to deploy job for compose variable expansion
- Replace simple docker compose up with network stripping workaround
(Docker 24 compose fails on external networks during container creation)
- Connect containers to networks manually after compose creates them
- Add smoke tests via docker exec against localhost:4000
- Create internal network manually when compose skips it
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
- Change port binding from 127.0.0.1:4001:4000 to 4001:4000 so CI containers
can reach the dashboard from any network namespace
- Run smoke tests via docker exec against localhost:4000 instead of curling
the external hostname, which resolves to the Caddy VPS and times out
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Container runtime needs SECRET_KEY in the shell environment so docker
compose can expand ${SECRET_KEY} from the compose file.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Claude CI Bot