Skip to content

chore(stainless): migrate SDK generation config into the repo - #433

Merged
aringuyen3 merged 7 commits into
mainfrom
aringuyen/stainless
Sep 21, 2026
Merged

aringuyen3 merged 7 commits into
mainfrom
aringuyen/stainless

Conversation

@aringuyen3

@aringuyen3 aringuyen3 commented Sep 15, 2026

Copy link
Copy Markdown
Contributor

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.json points at agentex/openapi.yaml — the spec generated by
    make gen-openapi — so there is no second copy of the spec to drift.
  • stainless.yml holds the config: targets, environments, resources, auth and
    spec transforms. Targets point at the existing staging and production SDK repos.
  • custom-code/ carries one tracking file per target, pointing at the sealed
    custom-code commits in the staging SDK repos — this is how hand-written SDK
    code survives regeneration.
  • sdks/ and builds/ are gitignored; generated output is not committed here.

The hosted Stainless build (.github/workflows/stainless.yml) is unchanged and
still runs — this PR does not retire it.

No product code changes: nothing under agentex/ or agentex-ui/ is touched.

🤖 Generated with Claude Code

RetriggerConfidence Score: 4/5

The code behavior looks safe, but the untracked TODOs must be linked to Linear tasks before merge.

What we checked:

  • Production SDK calls localhost: Yes. production now uses the deployed HTTPS address, while localhost stays under development.

Summary

The Stainless SDK generation setup now lives in the repository and uses the checked-in OpenAPI spec. It defines TypeScript and Python targets, API resources, publishing settings, authentication, and custom-code tracking without changing product code or the existing hosted workflow.

Diagram
sequenceDiagram
    participant Dev as Developer
    participant WS as stainless/workspace.json
    participant Spec as agentex/openapi.yaml
    participant Config as stainless/stainless.yml
    participant Gen as Stainless
    participant SDK as Generated SDK

    Dev->>Gen: Run generation with workspace
    Gen->>WS: Read workspace paths
    WS-->>Gen: Point to spec and config
    Gen->>Spec: Read API schema
    Gen->>Config: Read targets, auth, resources, and URLs
    Gen->>SDK: Write Python and TypeScript output
    SDK->>Config: Use production or development API URL
Loading

Reviews (4) · Last reviewed commit: "Merge branch 'main' into aringuyen/stain..."

@aringuyen3
aringuyen3 requested a review from a team as a code owner September 15, 2026 22:03
Comment thread stainless/stainless.yml Outdated
Comment thread stainless/workspace.json
{
"openapi_spec": "../agentex/openapi.yaml",
"stainless_config": "stainless.yml",
"output_path": "./sdks"

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not super familiar but is this an artifact of testing locally? Shouldn't the output path be to the sdk repos?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

./sdks is stlc's checkout area for the SDK repos, not a build output dir — it's gitignored, and the actual destinations are the staging_repo/production_repo entries in stainless.yml.

python:
  production_repo: scaleapi/scale-agentex-python
  staging_repo: scaleapi/scale-agentex-python-staging
  publish: { pypi: true }

@declan-scale declan-scale left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just the one question, otherwise looks good

aringuyen3 and others added 6 commits September 16, 2026 18:31
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>
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>
@aringuyen3
aringuyen3 merged commit 7958e88 into main Sep 21, 2026
14 checks passed
@aringuyen3
aringuyen3 deleted the aringuyen/stainless branch September 21, 2026 19:50
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.

2 participants