Consume the shared scclient module for the /cli client and credentials #19

Merged
geusebio merged 2 commits from feature/consume-scclient into main 2026-08-08 12:47:37 +00:00
Owner

What

Move the wire-contract half of internal/client (the /cli reads, FollowLogs, APIError, the request/error discipline) and the whole credential store to the new shared module someones.computer_scclient, so sc and the incoming sc-tray consume one client instead of forking it. Part of the tray-app plan (platform repo docs/tray-app.md).

What stays here is what sc alone owns:

  • internal/upload (was the other half of internal/client) — the multipart bundle upload and its progress seam, now composing on scclient's exported NewRequest/HTTPClient
  • internal/config — the .sc.yml project file only; the credential store is scclient's config package now (same file on disk, same semantics — sc login still writes it, sc-tray reads it)

Why the vendor directory

The scclient module is private and Forgejo's Actions token is repo-scoped, so a module fetch inside CI has no credential. Vendoring makes every build offline and deterministic; the goreleaser go mod tidy hook goes for the same reason. Local development against an unpushed scclient goes through the platform repo's go.work spanning the submodules. If a cross-repo deploy token lands later, the vendor tree can be dropped in one commit.

Verification

go vet ./..., go test ./... (all packages), go build ./... and cross-compiles for linux/amd64+arm64 and windows/amd64 — all green locally on the vendored tree, no network needed.

## What Move the wire-contract half of `internal/client` (the `/cli` reads, `FollowLogs`, `APIError`, the request/error discipline) and the whole credential store to the new shared module [`someones.computer_scclient`](https://git.grey.ooo/Grey.ooo/someones.computer_scclient), so `sc` and the incoming `sc-tray` consume one client instead of forking it. Part of the tray-app plan (platform repo `docs/tray-app.md`). What stays here is what `sc` alone owns: - **`internal/upload`** (was the other half of `internal/client`) — the multipart bundle upload and its progress seam, now composing on scclient's exported `NewRequest`/`HTTPClient` - **`internal/config`** — the `.sc.yml` project file only; the credential store is scclient's `config` package now (same file on disk, same semantics — `sc login` still writes it, sc-tray reads it) ## Why the vendor directory The scclient module is private and Forgejo's Actions token is repo-scoped, so a module fetch inside CI has no credential. Vendoring makes every build offline and deterministic; the goreleaser `go mod tidy` hook goes for the same reason. Local development against an unpushed scclient goes through the platform repo's `go.work` spanning the submodules. If a cross-repo deploy token lands later, the vendor tree can be dropped in one commit. ## Verification `go vet ./...`, `go test ./...` (all packages), `go build ./...` and cross-compiles for linux/amd64+arm64 and windows/amd64 — all green locally on the vendored tree, no network needed.
Consume the shared scclient module for the /cli client and credentials
All checks were successful
CI / build (pull_request) Successful in 2m26s
cb8557577f
The wire-contract half of internal/client (Client, the /cli reads,
FollowLogs, APIError) and the credential store move to
git.grey.ooo/Grey.ooo/someones.computer_scclient, shared with the
sc-tray app so the contract cannot fork between its consumers. What
stays is what sc alone owns: the bundle upload (now internal/upload,
composing on scclient's NewRequest/HTTPClient seam) and the .sc.yml
project file (internal/config).

Dependencies are vendored so CI builds offline — the scclient module is
private and the Actions token is repo-scoped, so a module fetch in CI
has no credential. The goreleaser tidy hook goes for the same reason.
Local development against an unpushed scclient goes through the
platform repo's workspace instead (go.work spanning the submodules).
geusebio changed title from WIP: Consume the shared scclient module for the /cli client and credentials to Consume the shared scclient module for the /cli client and credentials 2026-08-08 11:33:41 +00:00
Merge origin/main (#17, #18) across the scclient extraction
All checks were successful
CI / build (pull_request) Successful in 4m57s
84570a51a1
Two resolutions beyond what git managed alone:

- #17's refusal decoding landed in files this branch moved to the
  scclient module, so its substance moved there too: apiErrorFrom is
  now scclient's exported APIErrorFrom (pushed as 4dda771), the upload
  wraps it from its new home in internal/upload, and the upload's
  refusal test came along as internal/upload/client_test.go. The /cli
  half of the old test file already lives in scclient's suite.
- vendor/ regenerated against the bumped scclient rather than keeping
  git's rename-followed auto-merge of the vendored copy.
Sign in to join this conversation.
No reviewers
No labels
in-progress
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
Grey.ooo/someones.computer_agent!19
No description provided.