Publish worktable and worktable_codegen to crates.vip - #84
Conversation
Calls the reusable workflow in api.crates.vip, which packages the crate, derives its sparse-index entry from cargo metadata and writes both to Tigris under conditional requests. Manual dispatch, because a published version is immutable and cargo package embeds the git sha, so the same version from a different commit is refused rather than replaced.
api.crates.vip is now crates.vip-backend, matching the fleet convention where a backend is <domain>-backend. GitHub redirects the old path, but a workflow reference should name the repo that exists.
|
Two notes from the beta.17 consolidation in #87, neither blocking this PR. This workflow has the same gap the crates.io one had. It needs a third job, No file conflict with #87. That PR rewrites the publish step inside Left open rather than closed in the PR consolidation, because it is registry plumbing rather than a release change. |
|
Folded into #87, which is now the single beta.17 PR for this repo. Every commit from this branch is on |
Adds a manual-dispatch workflow that publishes both crates to the private registry at crates.vip.
The work happens in
api.crates.vip's reusable workflow:cargo package, then the sparse-index entry derived fromcargo metadata, then two writes to Tigris — the tarball underIf-None-Match: *and the index entry read-modify-written underIf-Match. Nothing is installed; the runner image already shipsawsandjq.codegenpublishes beforeworktable, sinceworktabledepends on it and the entry has to be resolvable first.Manual dispatch on purpose. A published version is immutable, and
cargo packageembeds the git sha in.cargo_vcs_info.json— so republishing a version from a different commit is refused rather than silently replaced. Run it withdry-runfirst to see the derived entry without writing.Secrets
CRATES_VIP_TIGRIS_KEY_ID/CRATES_VIP_TIGRIS_KEY_SECRETare already set on this repository.Consuming side, once published: