Skip to content

feat(sdk): sdk push — publish an external-mode SDK to its own repository - #114

Merged
ShocOne merged 1 commit into
mainfrom
feat/sdk-push
Aug 5, 2026
Merged

feat(sdk): sdk push — publish an external-mode SDK to its own repository#114
ShocOne merged 1 commit into
mainfrom
feat/sdk-push

Conversation

@ShocOne

@ShocOne ShocOne commented Aug 5, 2026

Copy link
Copy Markdown
Member

Why

The last open item from the kiota plan: external-mode SDKs (sdk generate -mode external) produce a standalone tree with its own go.mod, but there was no pipeline verb to publish it. sdk push is the SDK counterpart of provider push.

What

Same machinery, shared not copied: repo parsing (owner/name, https, ssh, enterprise, file://), the environment-only token (TFPFGEN_GITHUB_TOKEN / GITHUB_TOKEN) reaching git as GIT_CONFIG_* rather than argv, shallow-clone → sync → prune → generator-owned force-pushed branch (tfpfgen/sdk-<digest>) → open-or-find PR. The only refactor: openPullRequest takes title/body from the caller.

Provenance swaps records — the kiota lock stands where the manifest stood:

  • No kiota-lock.json → refused ("run sdk generate first").
  • No go.mod → refused by name: an embedded SDK's import path only works inside the provider module; only -mode external output can live in its own repository.
  • Branch digest from the lock (one generation = one branch); commit + PR name the kiota version and pinned document hash.

Pruning needed one new idea. The SDK root can't carry a manifest — sdk generate -check byte-compares it against fresh kiota output. So each push writes the inventory (.tfpfgen/manifest.json, deterministic: sorted entries, no timestamp) into the target repository, and the next push prunes against it. The target's own files (licence, workflows) are never touched — the same ownership rule provider push enforces.

Verification

  • Unit suite mirrors provider push's: refusals name their cause (lock, embed, token), first push syncs + prunes the previous generation's orphan + preserves target-owned files + carries the provenance message, second identical push is a no-op (proving manifest determinism), dry run pushes nothing.
  • End-to-end with real kiota output: generated a /tags-scoped external SDK (builds standalone), pushed to a local bare repo — 38 files on tfpfgen/sdk-9f86b66f9b0c, LICENSE untouched, correct commit message; merged and re-pushed → clean no-op.
  • Full root suite 0 failures; docs drift test green (sdk push section + commands table).

This closes the kiota plan's last open item.

🤖 Generated with Claude Code

…tory

The SDK counterpart of provider push, sharing its machinery: the same
repo parsing, the same environment-only token that reaches git as
configuration rather than argv, the same shallow-clone/sync/prune flow,
the same generator-owned force-pushed branch namespace, and the same
open-or-find pull request -- openPullRequest now takes its title and body
from the caller, which is the whole of the refactor.

Provenance swaps records: the kiota lock stands where the manifest stood.
A tree without one was not generated by this pipeline and is refused; a
tree without a go.mod is an embedded SDK -- whose import path only works
inside the provider module -- and is refused by name. The branch digest
comes from the lock, so one generation always names one branch, and the
commit and pull request name the kiota version and the pinned document's
hash.

Pruning needed one new idea: the SDK root cannot carry a manifest of its
own, because sdk generate -check byte-compares it against fresh kiota
output. So each push writes the inventory into the target repository
instead -- deterministic by construction, no timestamp, sorted entries --
and the next push prunes against it, leaving the target's own files
untouched. Proven end to end against a real kiota-generated external
tree: 38 files land, the licence survives, and pushing the same
generation twice is a no-op.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@ShocOne
ShocOne merged commit f659f7c into main Aug 5, 2026
13 of 17 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant