dev-worker: Added an admin CLI (cmd/warehouse-admin) for access key man… #3

Merged
pchapman merged 1 commit from dev-worker/01KYV7FSH9XKDDXVKD3YXKACP1 into main 2026-07-30 23:45:03 -05:00
Collaborator

Added an admin CLI (cmd/warehouse-admin) for access key management, exposing the existing internal/db CRUD operations.

Commands:

  • warehouse-admin access-key create [--owner OWNER] [--db PATH]: generates AWS-style random key material (AKIA-prefixed id + base64 secret), persists it via Store.CreateAccessKey, prints the credentials.
  • warehouse-admin access-key list [--db PATH]: lists all access keys with id, owner, ENABLED status (yes/no from active/disabled), and created_at in a human-readable table; prints "No access keys." when empty.
  • warehouse-admin access-key delete <ID> [--db PATH]: removes a key by id, translating ErrAccessKeyNotFound to a friendly "no such key" message.

Implementation notes / assumptions:

  • The CLI uses flag.FlagSet subcommands; command logic is split into a run() entrypoint that accepts an injected *db.Store so tests exercise create/list/delete against an in-memory SQLite store (db.Open with TestMode) without touching the filesystem. In production it opens the store from --db (default data/warehouse.db), matching the warehouse server.
  • ENABLED status is derived from the access_keys.status column: "active" => yes, anything else => no. The schema only documents active/disabled.
  • Key material is generated with crypto/rand: id is "AKIA" + 16 base32 chars, secret is 40 base64-raw chars.
  • Added cmd/warehouse-admin/main_test.go covering create+persist verification, list (status column + empty case), delete (success + missing + missing-arg), empty-owner validation, and generateKeyMaterial randomness/uniqueness.
  • internal/db/models.go and cmd/warehouse/main.go were not modified; the existing CRUD signatures already matched what the CLI needed.

Build, go vet, gofmt, and tests all pass.

go build ./...

(build succeeded, no output)

go test ./...

?   	pcsw/warehouse/cmd/warehouse	[no test files]
ok  	pcsw/warehouse/cmd/warehouse-admin	(cached)
ok  	pcsw/warehouse/internal/auth	(cached)
ok  	pcsw/warehouse/internal/db	(cached)
ok  	pcsw/warehouse/internal/server	(cached)

Opened by saga-dev-worker for mission 01KYV7FSH9XKDDXVKD3YXKACP1.

Added an admin CLI (cmd/warehouse-admin) for access key management, exposing the existing internal/db CRUD operations. Commands: - `warehouse-admin access-key create [--owner OWNER] [--db PATH]`: generates AWS-style random key material (AKIA-prefixed id + base64 secret), persists it via Store.CreateAccessKey, prints the credentials. - `warehouse-admin access-key list [--db PATH]`: lists all access keys with id, owner, ENABLED status (yes/no from active/disabled), and created_at in a human-readable table; prints "No access keys." when empty. - `warehouse-admin access-key delete <ID> [--db PATH]`: removes a key by id, translating ErrAccessKeyNotFound to a friendly "no such key" message. Implementation notes / assumptions: - The CLI uses flag.FlagSet subcommands; command logic is split into a run() entrypoint that accepts an injected *db.Store so tests exercise create/list/delete against an in-memory SQLite store (db.Open with TestMode) without touching the filesystem. In production it opens the store from --db (default data/warehouse.db), matching the warehouse server. - ENABLED status is derived from the access_keys.status column: "active" => yes, anything else => no. The schema only documents active/disabled. - Key material is generated with crypto/rand: id is "AKIA" + 16 base32 chars, secret is 40 base64-raw chars. - Added cmd/warehouse-admin/main_test.go covering create+persist verification, list (status column + empty case), delete (success + missing + missing-arg), empty-owner validation, and generateKeyMaterial randomness/uniqueness. - internal/db/models.go and cmd/warehouse/main.go were not modified; the existing CRUD signatures already matched what the CLI needed. Build, go vet, gofmt, and tests all pass. ## go build ./... ``` (build succeeded, no output) ``` ## go test ./... ``` ? pcsw/warehouse/cmd/warehouse [no test files] ok pcsw/warehouse/cmd/warehouse-admin (cached) ok pcsw/warehouse/internal/auth (cached) ok pcsw/warehouse/internal/db (cached) ok pcsw/warehouse/internal/server (cached) ``` --- Opened by saga-dev-worker for mission `01KYV7FSH9XKDDXVKD3YXKACP1`.
Commands:
- `warehouse-admin access-key create [--owner OWNER] [--db PATH]`: generates AWS-style random key material (AKIA-prefixed id + base64 secret), persists it via Store.CreateAccessKey, prints the credentials.
- `warehouse-admin access-key list [--db PATH]`: lists all access keys with id, owner, ENABLED status (yes/no from active/disabled), and created_at in a human-readable table; prints "No access keys." when empty.
- `warehouse-admin access-key delete <ID> [--db PATH]`: removes a key by id, translating ErrAccessKeyNotFound to a friendly "no such key" message.

Implementation notes / assumptions:
- The CLI uses flag.FlagSet subcommands; command logic is split into a run() entrypoint that accepts an injected *db.Store so tests exercise create/list/delete against an in-memory SQLite store (db.Open with TestMode) without touching the filesystem. In production it opens the store from --db (default data/warehouse.db), matching the warehouse server.
- ENABLED status is derived from the access_keys.status column: "active" => yes, anything else => no. The schema only documents active/disabled.
- Key material is generated with crypto/rand: id is "AKIA" + 16 base32 chars, secret is 40 base64-raw chars.
- Added cmd/warehouse-admin/main_test.go covering create+persist verification, list (status column + empty case), delete (success + missing + missing-arg), empty-owner validation, and generateKeyMaterial randomness/uniqueness.
- internal/db/models.go and cmd/warehouse/main.go were not modified; the existing CRUD signatures already matched what the CLI needed.

Build, go vet, gofmt, and tests all pass.
pchapman deleted branch dev-worker/01KYV7FSH9XKDDXVKD3YXKACP1 2026-07-30 23:45:03 -05:00
Sign in to join this conversation.
No reviewers
No labels
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
pcsw/warehouse!3
No description provided.