Commit Graph
3 Commits
Author SHA1 Message Date
Omar SobhandClaude Opus 5 ee1cea72d9 ci: mount the docker socket so the testcontainers suite can run
deploy / test (push) Failing after 2m54s
deploy / build (push) Skipped
cm-files' s3_store test starts a real MinIO via testcontainers. Without the
socket it does not skip — it fails with
`Client(Init(SocketNotFoundError("/var/run/docker.sock")))`, which looks like a
broken test rather than a missing capability. It passed locally only because the
Mac's docker socket was visible to the test process.

Sibling containers testcontainers starts are reachable because the test
container already shares the host network.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-08-13 10:13:26 -07:00
Omar SobhandClaude Opus 5 8129f58845 ci: give cargo the credential for the private clawhdf5 git dep
deploy / test (push) Failing after 5m38s
deploy / build (push) Skipped
First run failed in `cargo test --workspace`: "failed to load source for
dependency clawhdf5", preceded by three "spurious network error: invalid packet
line" retries. Two separate causes, both needed:

- libgit2 cannot fetch from Gitea's smart-HTTP. images/server.Dockerfile already
  sets CARGO_NET_GIT_FETCH_WITH_CLI for exactly this; the test step did not.
- quantumclaw/clawhdf5 is private (401 anonymous), so the CLI fetch needs a
  credential. Supplied via an insteadOf rewrite from a repo secret, so the token
  is masked in logs and never committed.

The server image build does not hit this — it builds only clawmates-server,
which does not pull cm-brain's clawhdf5 path.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-08-13 10:06:34 -07:00
Omar SobhandClaude Opus 5 b1bf50160a ci: build and deploy to production from a push to main
deploy / test (push) Failing after 42s
deploy / build (push) Skipped
Closes the one manual step left in the pipeline. gw-04 has run
clawmates-deploy.timer every minute since July, pulling :latest and rolling on
drift — the CD half already worked. What was missing was anything that moved
:latest, since the old build host (tank) is packed for the move.

The runner lives on gw-04 because it is the only reachable x86_64 host and prod
images must be linux/amd64: web-01 is aarch64 and the fleet build boxes are
offline. Host executor, capacity 1, so builds serialize rather than competing
with production traffic.

Three details that are not obvious:
- `docker push :latest` does NOT move the tag on this registry once the manifest
  exists under another tag. The PUT-the-manifest step is what actually moves it,
  and its absence is how a "successful" deploy could leave prod on a stale image.
- The final step verifies the image prod is RUNNING, not the one we pushed. A
  green edge on the old image is the failure this pipeline exists to prevent.
- broker is built here too. It had no :latest tag at all, so gw-04's deploy loop
  logged a pull failure every single cycle since 2026-08-11.

Also ignore the local env backups: `.env` was ignored but `.env.bak.*` was not,
and those copies hold real credentials.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-08-13 10:03:35 -07:00