Repository navigation
chore(deps): migrate provider-runtime and plumbing to the krateo-platformops fork - #14
Merged
braghettos merged 2 commits intoSep 16, 2026
Conversation
…formops fork git-provider depended on github.com/krateoplatformops/provider-runtime (upstream), while core-provider and the rest of the platform are on github.com/krateo-platformops/* (the fork). The two are not interchangeable: the org name is part of the Go import path, so the libraries were separate modules with separate types. That split is why the fix for the interrupted create handshake (krateo-platformops/provider-runtime#7, for core-provider#110) could not reach git-provider — and git-provider's LocalResource objects are exactly the ones wedged by it on krateo-057. Migrating is what makes that fix apply here. provider-runtime krateoplatformops v1.2.1 -> krateo-platformops v1.3.0 plumbing krateoplatformops v1.7.1 -> krateo-platformops v1.14.3 plumbing has to move with it: the two are coupled through the event.Recorder interface, so a mixed pair does not type-check. All eight provider-runtime packages this repo imports exist unchanged in the fork (apis/common/v1, pkg/{context,controller,logging,meta, ratelimiter,reconciler,resource}), so the change is an import-path rename plus the two go.mod lines. No Kubernetes bump was needed — resolution lands on client-go v0.35.3 / controller-runtime v0.23.3, matching core-provider exactly. One deliberate behaviour change: the fork's plumbing has no slogs/pretty, so logging moves to the shared logger.NewHandler. git-provider now emits one JSON object per line in the OTel log model instead of coloured console output — the same stream every other Krateo component produces, and logs-ingester compatible. Build, vet and all nine test packages pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017tUn92TdGikKGEN5opGD7q
v1.3.1 carries krateo-platformops/provider-runtime#7: an interrupted create handshake is now resolved by asking Observe whether the external resource exists, instead of refusing with Requeue:false and waiting for a human to delete the krateo.io/external-create-pending annotation. That is the fix this migration exists to deliver. publish-pet-000 on krateo-057 has been wedged on exactly that annotation for six days, with its git push already succeeded on the server — the case v1.3.1 adopts automatically. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017tUn92TdGikKGEN5opGD7q
braghettos
deleted the
fix/migrate-to-krateo-platformops-provider-runtime
branch
September 16, 2026 22:13
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.
Companion to krateo-platformops/provider-runtime#7, which fixes the interrupted create-handshake wedge (krateo-platformops/core-provider#110).
Why this is needed for that fix to matter
The org name is part of the Go import path, so
krateoplatformops/*andkrateo-platformops/*are separate modules with separate types. git-provider was on upstream; core-provider and the rest of the platform are on the fork. That's why the #110 fix couldn't reach git-provider — and git-provider'sLocalResourceobjects are precisely the ones wedged by it on krateo-057 (publish-pet-000, stuck 6 days).plumbing must move with it — the two are coupled through the
event.Recorderinterface, so a mixed pair doesn't type-check.Scope is smaller than it looks
All eight provider-runtime packages this repo imports exist unchanged in the fork:
apis/common/v1,pkg/{context,controller,logging,meta,ratelimiter,reconciler,resource}. So it's an import-path rename plus twogo.modlines.No Kubernetes bump needed — resolution lands on
client-go v0.35.3/controller-runtime v0.23.3, matching core-provider exactly.One deliberate behaviour change
The fork's plumbing has no
slogs/pretty, so logging moves to the sharedlogger.NewHandler. git-provider now emits one JSON object per line in the OTel log model instead of coloured console output — the same stream every other Krateo component produces, and logs-ingester compatible. Flagging it explicitly because it changes what operators see inkubectl logs; if coloured console output is wanted for local runs, that's a follow-up.Verification
go build ./...,go vet ./..., and all 9 test packages pass.Sequencing
provider-runtime#7 should merge and be tagged first; this PR can then be repointed from
v1.3.0to that release so git-provider picks up the #110 fix in the same move. As it stands this migration is behaviour-neutral apart from the logging note.🤖 Generated with Claude Code
https://claude.ai/code/session_017tUn92TdGikKGEN5opGD7q