stacklok / toolhive / 30081604025

69%

Build Type

push

github

Committed by web-flow

Commit Message

Record project-scope skill installs in the lock file (#5894)

* Record project-scope skill installs in the lock file

RFC THV-0080 requires every project-scoped skill install to be
pinned in toolhive.lock.yaml, including transitively materialized
toolhive.requires dependencies, with a fail-hard guarantee so a
lock-write failure never leaves an install silently unpinned.

The whole feature stays inert on main until the full RFC v1 (this
lock-file stack plus the later Sigstore stack) has landed — gated
behind TOOLHIVE_SKILLS_LOCK_ENABLED, following the existing
TOOLHIVE_DEV precedent for staged rollouts. Each PR in the stack is
independently mergeable without exposing partial behavior.

- Install hooks into the single choke point (installAndRegister):
  compute contentDigest, upsert the lock entry, roll back the DB
  record if the lock write fails
- toolhive.requires dependencies materialize recursively (visited
  set guards cycles, skills.MaxDependencies bounds the whole tree),
  with RequiredBy merged across shared dependencies
- Uninstall cascades to orphaned, non-explicit dependencies via
  Lockfile.RemoveParentFromRequiredBy, itself cycle-safe
- E2E coverage for the real HTTP API + thv serve subprocess path

Part of the production stack for #5715 (RFC THV-0080). Stack: 3/6.

* Fix CI failure: gitRef test fixture hardcoded http scheme

gitresolver.ParseGitReference only uses "http://" when
TOOLHIVE_DEV=true; the correct default (and what GitHub Actions
CI runners use, since they don't set that var) is "https://".
The gitRef test helper hardcoded "http://" for the fixture
registration key, so every test using it failed in CI with
"no fixture registered for https://...". Compute the scheme the
same way the resolver does instead of hardcoding either one.

* Fix install rollback and dependency cycle detection gaps

installAndRegister's rollback only deleted the DB record, so a
dependency-materialization failure after the parent's own lock entry
had alre... (continued)

Coverage Stats

253 of 291 new or added lines in 7 files covered. (86.94%)

6 existing lines in 3 files now uncovered.

78164 of 112733 relevant lines covered (69.34%)

80.18 hits per line