fix(hosting): bundle SeaweedFS store in gh.local and gh.ssl variants - #5315
Conversation
…ompose variants PR #5313 added the bundled store and flipped the gh env default to http://seaweedfs:8333, but only added the service to docker-compose.gh.yml. The gh.local (build-from-source) and gh.ssl variants reuse the same gh env file, so they inherited the endpoint default with no such service on the network. Add the identical seaweedfs service, api depends_on, and seaweed-data volume to oss gh.local, oss gh.ssl, and ee gh.local, plus a multi-replica JWT note in the gh env examples. Claude-Session: https://claude.ai/code/session_01XhENr63WL9npkKrJGnzDc1
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
What and why
Merged PR #5313 bundled the SeaweedFS durable object store into the published gh compose, but only added the
seaweedfsservice todocker-compose.gh.yml. It also flipped the gh env examples to defaultAGENTA_STORE_ENDPOINT_URL=http://seaweedfs:8333.The three other gh-family compose files reuse the same
.env.*.ghfile, so they inherited that endpoint default — but shipped noseaweedfsservice. On those stages the store now points at a phantom host: runner mount signing returns 503 and agent file writes are silently lost.This adds the identical bundled store to the affected variants.
Changes
For each of the three compose files below, the same three pieces from
docker-compose.gh.ymlwere replicated verbatim (adapting only the network name and theenv_filedefault):seaweedfs:service block (imagechrislusf/seaweedfs:4.37, loopback-only${AGENTA_STORE_PORT:-127.0.0.1:8333}:8333,-ip=seaweedfs, the s3.json/iam.json heredoc, and the healthcheck),seaweedfs: {condition: service_healthy}on theapiservice'sdepends_on,seaweed-data:volume.hosting/docker-compose/oss/docker-compose.gh.local.yml— networkagenta-oss-gh-network, env.env.oss.ghhosting/docker-compose/oss/docker-compose.gh.ssl.yml— networkagenta-gh-ssl-network, env.env.oss.ghhosting/docker-compose/ee/docker-compose.gh.local.yml— networkagenta-ee-gh-network, env.env.ee.ghThere is no
ee/docker-compose.gh.ssl.yml, so none was created.Plus a multi-replica JWT note (2 files): near the commented
AGENTA_STORE_JWT_PRIVATE_KEYline inenv.oss.gh.exampleandenv.ee.gh.example, explaining that the bundled store's web-identity path mints an ephemeral keypair per api process (a single api replica works with the key unset), and that scaling the api past one replica requires the same PEM on every replica or STS minting fails intermittently.Verification
docker compose -f <file> --env-file <env-example> configparses cleanly for all three files. Rendered output confirms per file:chrislusf/seaweedfs:4.37127.0.0.1:8333:8333service_healthychrislusf/seaweedfs:4.37127.0.0.1:8333:8333service_healthychrislusf/seaweedfs:4.37127.0.0.1:8333:8333service_healthy(The ee parse needs
ENV_FILE=./env.ee.gh.examplesince.env.ee.ghis not committed; that is pre-existing and unrelated to this change.)Coordination
@jp-agenta is concurrently fixing the runner
dockerfile:line in these same three compose files (fix/runner-dockerfile-gh-path, #5314). Those hunks are in the runner service region; the hunks here are the newseaweedfsservice block, theapidepends_on, and theseaweed-datavolume — disjoint regions, no conflict encountered.