Repository Endpoints CLI Usage Analysis
can you tell me which repository endpoints are used against core or cell from the cli
The search agent is running. I'll report back once it completes its scan of the repository command implementations and API client packages.
Here's the map of repository endpoints and which plane each one hits.
CORE (control-plane, coreapi → <core-host>/api/v1)
The entire entire repo command group runs against core. Wiring in repo.go:21, dialed via the runCore* helpers in corecmd.go.
repo group:
| Command | Method + path |
|---|---|
repo create <name> | POST /api/v1/repos |
repo list <project> | GET /api/v1/projects/{projectId}/repos |
repo get <repo> | GET /api/v1/repos/{repoId} |
repo delete <repo> | DELETE /api/v1/repos/{repoId} |
repo visibility get <repo> | GET /api/v1/repos/{repoId}/visibility |
repo visibility set <repo> <vis> | PUT /api/v1/repos/{repoId}/visibility |
repo mirror subtree (repo_mirror.go:121) — also all core:
| Command | Method + path |
|---|---|
repo mirror create <url> [cluster] | POST /api/v1/mirrors (+ poll GET /api/v1/mirrors/{id} for clone-readiness) |
repo mirror list | GET /api/v1/mirrors |
repo mirror list --show-available | GET /api/v1/mirrors/available |
repo mirror get <mirror> | GET /api/v1/mirrors/{id} (+ GET /api/v1/mirrors to resolve a URL ref → ULID) |
repo mirror remove <url> [cluster] | DELETE /api/v1/mirrors?provider&owner&repo&clusterHost |
repo mirror collaborators list <url> | GET /api/v1/mirrors/collaborators |
| (wizard region picker) | GET /api/v1/clusters |
Note: repo clone never makes the data-plane request itself. It resolves placements against core (GET /api/v1/mirrors), then shells out to git clone — the actual data transfer is done by the separate git-remote-entire helper (repo-scoped STS in internal/entireclient/repocreds/).
CELL (data-plane entire-api, auth.NewEntireAPICellClient → <cell>/api/v1)
Repo-scoped calls dialed directly at a specific cell with a jurisdictional identity token:
| Command | Method + path |
|---|---|
experts (resolve owner/repo → ULID) | GET /api/v1/repos |
experts (main call) | POST /api/v1/repos/{repoId}/experts |
activity / recap | GET /api/v1/me/recap?repo={ulid} (home cell) |
api --to cell <path> | raw passthrough to any /api/v1/… on home cell |
cell_fanout.go (multi-cell fan-out) exists but has no production caller yet — it's scaffolding for querying all of a caller's repos across cells.
Repo endpoints that hit BOTH (core to resolve → cell to call)
These are the cross-plane cases — core GET /api/v1/mirrors (the shared listMirrorsForRepo helper) turns origin into a repo ULID / cell target, then the real call goes to the cell:
experts— coreGET /api/v1/mirrors+GET /api/v1/clustersto pick the owning cell, then cellGET /api/v1/repos+POST /api/v1/repos/{repoId}/experts.recap/activity— coreGET /api/v1/mirrorsto get the ULID, then cellGET /api/v1/me/recap?repo={ulid}.api … {repo_id}— coreGET /api/v1/mirrorsto expand{repo_id}, then the templated request against--to coreor--to cell.
Aside: BFF data-API (api.BaseURL(), not a per-cell dial)
A few repo-related calls go to the entire.io BFF rather than a specific cell — worth distinguishing from the direct cell client:
search/dispatchrepo completion →GET /api/v1/repositories?sort=recentenable→POST /api/v1/cli/enablesearch(code search) → search service on the data-API host
Bottom line: all CRUD/mirror management (entire repo …) is core-only; repo content/insight endpoints (experts, recap, code search) live on the cells, and they lean on a core mirror lookup first to figure out which cell hosts the repo.