eblume/blumeops
1
1
Fork 0
Code Issues Pull requests Projects Releases 83 Packages Wiki Activity Actions

Review CV doc and close build-dep review gap

Browse source 
Fix stale CV service doc (URL, forge domain, container tag) and add
guidance for reviewing build-time dependencies in private forge repos
during service reviews.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Erich Blume 2026-03-27 07:11:22 -07:00
commit 687e972713
4 changed files with 24 additions and 8 deletions
Download patch file Download diff file Expand all files Collapse all files

14
docs/how-to/knowledgebase/review-services.md
View file

@ -38,6 +38,8 @@ mise run service-review --type hybrid
## Review Process by Service Type
For all service types, start by reading the service's reference card (`docs/reference/services/<service>.md`) for architecture, configuration, and endpoint details.
### ArgoCD Services (`type: argocd`)
1. Check the upstream releases page for new versions
@ -59,6 +61,18 @@ mise run service-review --type hybrid
2. Review the Nix derivation or flake input for version pins
3. If upgrading, update and deploy via `mise run provision-ringtail`
### Private Forge Repos (`upstream-source` under `forge.eblu.me/eblume/`)
Some services are built from private repos on the forge rather than tracking an external upstream project. When `upstream-source` points to a `forge.eblu.me/eblume/` repo:
1. Clone the repo to `~/code/personal/` if not already checked out
2. Review the repo's dependency pins — uv script metadata, `pyproject.toml`, `package.json`, `flake.nix` inputs, etc.
3. Update stale dependencies and rebuild locally to verify nothing breaks
4. If changes were made, commit, push, and trigger a new release from that repo
5. Back in blumeops, update the container image or release artifact reference as needed
This extends the service review into the source repo's build-time dependencies, which would otherwise be a blind spot — the blumeops-side review only covers the deployment manifest and container base image.
## Attached Services
Some services have auxiliary dependencies that run as separate containers — caches, sidecars, init helpers. These are tracked as **attached services** with a naming convention and an optional `parent` field: