Repository navigation
chore(companions): new versions carrying a codefly with the delivery verbs - #875
Merged
Merged
Conversation
…he delivery verbs Every companion bakes the codefly CLI, so a CLI change that an image must run needs a new tag for every one of them: publishing skips a tag the registry already has, and overwriting one would swap the image under every consumer that has resolved it. The CLI gains `codefly delivery prepare|apply`, which a cell's delivery Job runs from the `codefly` companion to send a module's signed pair (Core carrier plus the authority declaration) to the host's composition interface; the 0.0.6 image carries a codefly without that verb, so the Job cannot run it. codefly 0.0.6 -> 0.0.7, execution 0.0.2 -> 0.0.3, go 0.0.13 -> 0.0.14, node 0.0.15 -> 0.0.16, proto 0.0.23 -> 0.0.24, python 0.0.8 -> 0.0.9. The four dependents' CODEFLY_BASE_IMAGE defaults track the base, as buildspec_test requires. No Dockerfile input changes otherwise. Testing: go test ./companions/... and ./internal/ciguard/... pass; `go run ./internal/companionbump ghhttps/main` reports every changed companion carries a new version. Publishing is the CLI's Companions workflow against this commit, dispatched from the CLI ref that carries the verbs. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
antoinetoussaint-byte
added a commit
to codefly-dev/cli
that referenced
this pull request
Oct 29, 2026
…e first that carries the verb pairedDeliveryImage pinned companion 0.0.6, whose static codefly predates `delivery apply`, so a paired Job rendered against it failed on an unknown flag. Every companion bakes the CLI, so core bumped them all (codefly-dev/core#875) and the Companions workflow published 0.0.7 from this branch; its index digest is sha256:1cbd3826…, measured on linux/amd64 and linux/arm64 to answer `delivery apply --help`. A moved pin changes every cell's delivery declaration, so the cell is re-rendered with it; the docs say that instead of "not yet runnable". Testing: GOWORK=off go test ./pkg/gitops/ ok (222s). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
antoinetoussaint-byte
enabled auto-merge (squash)
October 29, 2026 17:39
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Every companion bakes the codefly CLI. The CLI gains
codefly delivery prepare|apply(codefly-dev/cli branchhandoff/wiki-builder-install-20261029): a cell's delivery Job runsapplyfrom thecodeflycompanion to send a module's signed pair — the Core carrier and the authority declaration signed against it — to the host'scodefly.dev/compositioninterface. That is what lets a GitOps rollout deliver a module's roles; the curl runner's REST route carries none, which is why Blue's accounts refuses to composewiki("0 roles and none installer") and the install review answersmodule "wiki": not found.The published
codefly:0.0.6carries a codefly built before the verb existed, so the Job cannot run it. Publishing skips a tag already in the registry, and--forcewould swap the image under every consumer that has resolved 0.0.6, so this is a version bump — and because every companion carries the CLI, every one of them bumps (the runbook's own rule).What
The four dependents'
CODEFLY_BASE_IMAGEdefaults follow the base to 0.0.7 (buildspec_testenforces it). No other Dockerfile input changes.Classification
chore, at the place that owns companion versions. Nothing reused or built; the publish itself is the existing CLI Companions workflow (workflow_dispatch,core_ref= this commit), run from the CLI ref carrying the verbs, asdocs/runbooks/publish-companions.mddescribes.Testing
go test ./companions/... ./internal/ciguard/...pass.go run ./internal/companionbump ghhttps/main: every companion whose image changed carries a new version.companions-buildbuilds every image from this branch, and the publish records the digests the consumers then pin.Refs obin-ai/infra-base#1509 (Blue delivery).
🤖 Generated with Claude Code