clawmates

775 Commits 5 Branches 0 Tags

2 Commits

Include renames

Author	SHA1	Message	Date
Omar SobhandClaude Opus 5	8129f58845	ci: give cargo the credential for the private clawhdf5 git dep deploy / test (push) Failing after 5m38s Details deploy / build (push) Skipped Details 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 Details deploy / build (push) Skipped Details 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

Author

SHA1

Message

Date

Omar SobhandClaude Opus 5

8129f58845

ci: give cargo the credential for the private clawhdf5 git dep

deploy / test (push) Failing after 5m38s

Details

deploy / build (push) Skipped

Details

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

Details

deploy / build (push) Skipped

Details

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