Repository navigation
refactor(fixture)!: the fixture API leaves the runtime root - #65
Merged
Merged
Conversation
Every service that imported `codefly` to resolve its own address also linked
a GitHub API client and an HTTP artifact downloader it never calls:
codefly-base -> sdk-go -> core/composition -> go-github/v89
The whole reason was fixture.go, 98 lines in the ROOT package, needing
core/composition for three types -- and composition carries GitHubResolver,
which downloads release artifacts. Resolving a seeded identity by role is a
TEST-time concern; a service binary has no business carrying the code that
fetches release assets from GitHub.
It moves to sdk-go/fixture: FixtureSelection becomes fixture.Selection,
codefly.Fixture() becomes fixture.Selected(), codefly.WithFixture() becomes
fixture.With(). Nothing is lost.
Breaking, and safe: a search across codefly-dev and obin-ai finds NO consumer
of the fixture API outside sdk-go's own test.
Proven, not assumed -- in a generated service, `go list -deps .` (the packages
the BINARY links) now matches neither core/composition nor go-github, while
core/resources is still linked for address resolution. The generated service's
go.mod no longer names go-github at all, which is what service-go's
manifest-guard refuses (codefly-dev/service-go#128).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Merged
4 tasks done
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.
What this is
Every service that imported
codeflyto resolve its own address also linked a GitHub API client and an HTTP artifact downloader it never calls:The entire reason was
fixture.go— 98 lines in the root package — needingcore/compositionfor three types.core/compositioncarriesGitHubResolver, which downloads release artifacts (artifact, provenance, signature, metadata assets) from GitHub releases.Resolving a seeded identity by role is a test-time concern. A service binary has no business carrying the code that fetches release assets from GitHub — it is dead weight in every image and a supply-chain surface in a process that should only ever talk to its own composition.
The change
The API moves to
sdk-go/fixture, losing nothing:codefly.Fixture()fixture.Selected()codefly.WithFixture(name)fixture.With(name)codefly.FixtureSelectionfixture.SelectionBreaking, and safe: a search across
codefly-devandobin-aifinds no consumer of the fixture API outside sdk-go's own test.Proven, not assumed
In a generated service,
go list -deps .— the packages the binary links, excluding test binaries — now matches neithercore/compositionnorgo-github, whilecore/resourcesis still linked for address resolution. The generated service'sgo.modno longer namesgo-githubat all.That is exactly what
service-go's manifest-guard refuses, so this unblocks codefly-dev/service-go#128, which gives that agent a resolving scaffold.go vetand the full suite are green.Worth knowing
GitHubResolverhas no consumer in core either — only the CLI uses it (pkg/composition/*), legitimately. So the alternative fix was moving the resolver into its own package in core; this one is smaller, single-repo, and targets the actual mistake: install-time code reachable from a runtime root package.🤖 Generated with Claude Code