Repository navigation
fix(companions): proto 0.0.18 for the streaming facade; refuse an unbumped companion change - #838
Merged
Merged
Conversation
…umped companion change 08716e9 changed the proto companion's Python facade plugin and kept 0.0.17. 0.0.17 had been published with the old plugin, then was republished with the new one, so a machine that cached the first image still renders every streaming RPC as `unary` (obin-ai/module-model- gateway#210's model client). Proto moves to 0.0.18, a tag no machine has cached. internal/companionbump, run by companions-build on every pull request, refuses a change to a companion's image inputs (its Dockerfile and every build-context COPY source: BuildSpec.Inputs) unless the companion's version is above the base's. Comparing with the base's tip also refuses a version another merged change already took. Run against 08716e9 it refuses exactly that change. The COPY parser the buildspec tests used moves into the package (CopySources) so the check and the tests read Dockerfiles one way. Closes #837 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…y copy shape count Review r65 on #838: - The check moves to its own workflow with no path filter, so it reports on every pull request and can be a required check of main's ruleset (a path-filtered required check stays pending on a PR it skips). - git diff runs with --no-renames: moving a file out of an input lists it at its old path too, so it no longer escapes. A test in a scratch repository fails without the flag. - The Dockerfile reader takes logical instructions (continued lines joined, comments inside them dropped) and reads ADD as well as COPY, in any case. An ADD of a URL or git remote and a heredoc are not context inputs. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…fe to require companion-version.yml runs on every pull request with a fixed job name, so ciguard derives it as safe to require; the pinned set and the branch-protection runbook's apply payload name it too. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This was referenced Oct 26, 2026
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.
Closes #837.
Why
08716e9 changed
companions/proto/facades/python/protoc_gen_codefly_facade_python.py(streaming RPCs get their own gateway seams) and keptprotoat 0.0.17. 0.0.17 had already been published with the old plugin (sha256:aa8d63e1) and was then republished with the new one (sha256:46e8b398). A machine that cached the first image keeps it, because the CLI reuses a cached tag. That is how obin-ai/module-model-gateway#210's Python model client came out with its four streaming RPCs asunary. codefly-dev/cli#1161's generator test fails against the first image and passes against the second.Change
companions/proto/info.codefly.yaml→ 0.0.18. The plugin change now ships under a tag no machine has cached. README notes which version carries the streaming facade.internal/companionbump:go run ./internal/companionbump <base-ref>. A newversionjob incompanions-build.ymlruns it on every pull request; the path filter also coversinternal/companionbump/**.BuildSpec.Inputs: its Dockerfile plus every build-contextCOPYsource, read from the Dockerfile itself. The staged CLI binary is excluded because it is built from codefly-dev/cli.companions.CopySources/CopyKind: the COPY parserbuildspec_test.goalready had, moved into the package so the check and the tests read Dockerfiles one way. The tests now call it. No second parser.Evidence
go run ./internal/companionbump 08716e9^refuses it, exit 1:companion <proto> changes its image (companions/proto/facades/python/protoc_gen_codefly_facade_python.py) but companions/proto/info.codefly.yaml says 0.0.17, and the base says 0.0.17: bump it above 0.0.17origin/main, it passes.go test ./internal/companionbump ./internal/buildspecs ./companions/ ./companions/proto/pass. Unit cases: unbumped refused, bumped passes, version already taken on the base refused, non-input and prefix-sibling paths ignored, new companion passes. One test also runs over the real specs.golangci-linton the touched packages adds no new findings; thegoconsthits inbuildspec.go/companions.gowere already on main.After merge
Publishing is a separate step: run the CLI's Companions workflow with
core_ref= this merge commit to pushproto:0.0.18. Then the CLI moves its core pin, and the CLI's verify gate needs 0.0.18 in the registry before that. I'll open the CLI pin PR once this merges.Classification
Fix, at the owner: core owns companion versions and their build inputs. Reused:
BuildSpecs, the existing COPY parser, the existingcompanions-buildworkflow. Not done: the Nix flake (companions/proto/flake.nix) is a local-only build definition and is not counted as an input. The published image comes from the Dockerfile.🤖 Generated with Claude Code