Repository navigation
ci(downstream): make zerodep-update workflows lock-aware and skip-safe #253
Description
What
Update the zerodep-update.yml workflows in toolregistry,
toolregistry-server, and toolregistry-hub to:
- install the CLI version that owns the release ref they consume;
- run
zerodep update --all(now skip-aware) instead of force-overwriting; - commit
zerodep.lock.jsontogether with the vendored files; - surface skipped locally-modified modules in the PR body or fail the job when
a manual merge is required.
Why
The automated PR currently force-overwrites any local patch. With the lock and
skip semantics, the workflow must carry the lock forward or the next run loses
the baseline.
Acceptance
- A run that has nothing to update exits cleanly without opening a PR.
- A run with a locally modified module opens a PR that does not touch that
file and says so. - The lock file is present and updated in the PR.
Activity
Oaklight commentedon Oct 23, 2026
Blocked on a release: the downstream workflows install the CLI from PyPI (
pip install zerodep>=2026.9.9), and the new lock/safe-update CLI only exists on master. A release also requires resolving #247 first — the trusted-publisher mismatch made the last PyPI upload fail.Plan once a release is out (new CLI installable):
zerodep.lock.jsonin each repo's vendor dir, pinned to that release tag (zerodep --ref v<release> add <modules> --forceor the per-moduleupdate <module> --diff/--forcepath), and commit it with the modules.status == 'outdated'filter inzerodep-update.ymlwithzerodep status --json, which understands every state. Open the PR when there is an updatable module (outdated/missing); listlocally-modified/conflict/unverified/upstream-removedin the PR body as needing a human instead of counting them as updates.zerodep update --all --check(exit 1 when anything needs attention) before writing, thenzerodep update --alland commit the refreshed lock.update --allexits 1 when it skipped a module, so the workflow must treat that as "needs human", not as a failed install.Oaklight commentedon Oct 23, 2026
Done in three downstream PRs, all merged after agent review and green CI: Oaklight/ToolRegistry#344, Oaklight/toolregistry-server#121, Oaklight/toolregistry-hub#221.
Each repo now commits a zerodep.lock.json pinned to v2026.10.23.1 (all module entries verified byte-exact against the tag manifest) and runs the rewritten zerodep-update.yml: install zerodep>=2026.10.23.1, read 'zerodep status --json', update only outdated/missing modules, verify with a second status that every previously-outdated module reached up-to-date, and report locally-modified/conflict/unverified/upstream-removed for a human instead of counting them as updates. Pending upstream versions on the first run: ToolRegistry httpclient 0.5.1->0.6.1, httpserver 0.5.1->0.6.1, jsonx 1.0.0->1.0.2; hub httpclient 0.5.1->0.6.1, soup 0.8.1->0.9.0; server was already current.