Problem
Adding a tool to ci-tools currently requires edits to 5 files:
Dockerfile — ARG + RUN block
compose.yaml — build args mapping
scripts/ci-tools/resolve.sh — resolver function + tool list
scripts/ci-tools/verify.sh — check call
versions.lock — initial entry
This creates friction and opportunities for missing a step, especially for npm/luarocks tools that follow an identical pattern.
Proposal
Explore whether a tool registry file (e.g. tools.yaml or a structured section in versions.lock) could reduce the number of manual touch points. For example, compose.yaml build args could be auto-generated from the lockfile, and npm tools could share a single templated Dockerfile block.
This is a design exploration — the current approach works fine, but may not scale well as tool count grows.
Context
Flagged during architectural review. Currently manageable with one image and ~10 tools, but worth considering before adding more.
Problem
Adding a tool to ci-tools currently requires edits to 5 files:
Dockerfile— ARG + RUN blockcompose.yaml— build args mappingscripts/ci-tools/resolve.sh— resolver function + tool listscripts/ci-tools/verify.sh— check callversions.lock— initial entryThis creates friction and opportunities for missing a step, especially for npm/luarocks tools that follow an identical pattern.
Proposal
Explore whether a tool registry file (e.g.
tools.yamlor a structured section inversions.lock) could reduce the number of manual touch points. For example, compose.yaml build args could be auto-generated from the lockfile, and npm tools could share a single templated Dockerfile block.This is a design exploration — the current approach works fine, but may not scale well as tool count grows.
Context
Flagged during architectural review. Currently manageable with one image and ~10 tools, but worth considering before adding more.