chore(stainless): migrate SDK generation config into the repo - #433
Open
aringuyen3 wants to merge 6 commits into
Open
aringuyen3 wants to merge 6 commits into
aringuyen3 wants to merge 6 commits into
Conversation
Adds the TypeScript and Python custom-code tracking files produced by the local stlc builds, and drops the superseded main-branch Python record. Its content is fully absorbed into the new seal — the two integrated trees have identical path sets — and its base/integrated refs remain on the staging SDK remote. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The latest local build moved the sealed base forward. Both the new base and the integrated commit are already on the staging SDK remote. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The workspace pointed at a copy written by stlc init. Nothing kept it in sync with the generated spec, so a merge or a release version bump would have silently split them and made local SDK generation build from a stale API surface. CI already reads the generated spec. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Two tracking files were sealed for branches no longer built here. stlc only consolidates records matching the current branch, so they would have been re-merged on every build forever while status claimed they were about to be consolidated. Both are fully absorbed into the surviving seal: identical tree path sets, and all 30 files the older record customizes have byte-identical blobs in it. The second pointed at the same integrated commit already. Re-sealing after removal produced no change, and their base/integrated refs remain on the staging SDK remote. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
Both environments were left on the scaffold default of http://localhost:5003, and production is what a client picks when no base URL is supplied — so a plain `Agentex(api_key=...)` called the developer's own machine instead of the API. Set production to the deployed endpoint and leave localhost as development. Regenerated both SDKs so the clients carry it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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
1 participant
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.
First step of the Stainless migration: the SDK generation config that lived in
the Stainless app now lives in this repo, versioned and reviewed alongside the
API it describes.
workspace.jsonpoints atagentex/openapi.yaml— the spec generated bymake gen-openapi— so there is no second copy of the spec to drift.stainless.ymlholds the config: targets, environments, resources, auth andspec transforms. Targets point at the existing staging and production SDK repos.
custom-code/carries one tracking file per target, pointing at the sealedcustom-code commits in the staging SDK repos — this is how hand-written SDK
code survives regeneration.
sdks/andbuilds/are gitignored; generated output is not committed here.The hosted Stainless build (
.github/workflows/stainless.yml) is unchanged andstill runs — this PR does not retire it.
No product code changes: nothing under
agentex/oragentex-ui/is touched.🤖 Generated with Claude Code
The code behavior looks safe, but the public employee details and untracked TODOs block merge under repository rules.
Summary
Stainless SDK generation setup now lives in the repository instead of only in the hosted Stainless app, while generated SDK output stays uncommitted.
sdks/andbuilds/output.Diagram
sequenceDiagram participant Dev as Developer participant Workspace as workspace.json participant Config as stainless.yml participant Spec as agentex/openapi.yaml participant Stainless participant Staging as SDK staging repos participant Output as sdks/ Dev->>Workspace: Start local SDK generation Workspace->>Config: Load generation config Workspace->>Spec: Load OpenAPI spec Config->>Stainless: Set targets and environments Stainless->>Staging: Read custom-code commit refs Stainless->>Output: Write generated SDKs Note over Output: Ignored by Git participant Actions as GitHub Actions Actions->>Spec: Sparse checkout OpenAPI spec Actions->>Stainless: Upload spec to hosted projectReviews (2) · Last reviewed commit: "fix(stainless): point the production SDK..."