build: re-bump speakeasy-core/client-sdk-go with registry auth fixed + regression coverage - #2121
Merged
Merged
Conversation
…and regression coverage Re-does #2117 (reverted in #2120): speakeasy-core v0.23.0 to capture the registry license token, and speakeasy-client-sdk-go v3.27.1 which restores auth on the artifacts/subscriptions operations that v3.27.0 silently dropped (generated from a composed spec that marked them 'security: []'; fixed at the source in speakeasy-registry#4707 and regenerated in speakeasy-client-sdk-go#51). Pinned to a v3.27.1 pseudo-version until the tag exists. Why nothing caught it last time: the SDK regression left every method signature unchanged — utils.PopulateSecurity simply vanished from those operations, so builds stayed green and the requests went out with no x-api-key. Registry e2e tests push/pull via oras/ocicommon credentials and never touch the generated SDK, and the only SDK callsites (registry/tagging.go PostTags, internal/remote/sources.go GetRevisions — which swallows errors) had no coverage. Two new guards: - internal/sdk/sdk_test.go: hermetic contract test asserting the x-api-key header is sent on Artifacts.PostTags and Artifacts.GetRevisions (verified to fail against v3.27.0). - integration/workflow_registry_test.go: TestRegistryFlow now finishes with 'speakeasy tag promote', exercising the platform-API auth path end-to-end (passes in 30s against prod).
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
1 issue found across 4 files
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="internal/sdk/sdk_test.go">
<violation number="1" location="internal/sdk/sdk_test.go:24">
P2: If `SPEAKEASY_SERVER_URL` is set in the test process, `InitSDKWithKey` will ignore `server.URL` and send these requests to the env URL instead. Clear that env before constructing the client, or this regression guard will become non-hermetic and can miss the auth path it is meant to pin down.</violation>
</file>
Reply with feedback, questions, or to request a fix.
Fix all with cubic | Re-trigger cubic
ThomasRooney
force-pushed
the
build/rebump-client-sdk-go-with-auth-fix
branch
from
August 25, 2026 10:40
865c9a7 to
6dea276
Compare
The v3.27.1 pseudo-version pointed at speakeasy-client-sdk-go#51, which was superseded by #52 (same auth fix, regenerated from the registry-published spec after speakeasy-registry#4705/#4707 merged) and tagged as v3.28.0.
AshGodfrey
approved these changes
Aug 26, 2026
ThomasRooney
added a commit
that referenced
this pull request
Aug 28, 2026
…2126) Dependency bump only, split out of #2124 so the SDK/core change ships and is verified on its own before the generator change. - `speakeasy-client-sdk-go/v3` v3.28.0 → **v3.28.1** (regenerated from the registry spec after speakeasy-registry#4708: `AccessDetails` gains `license_jwt` and `status_code`; no signature changes). - `speakeasy-core` v0.23.0 → **v0.24.0** (`access.CheckGenerationAccess` returns the full access decision including the platform-issued license token; `HasGenerationAccess` unchanged). No CLI behaviour change: nothing reads the token yet. #2124 (generator pin + commercial-on-token wiring) rebases on top once openapi-generation#55 is released. Guards from #2121 still apply: `internal/sdk/sdk_test.go` asserts `x-api-key` on `Artifacts.PostTags`/`GetRevisions`; `TestRegistryFlow` ends with `tag promote`. <!-- This is an auto-generated description by cubic. --> --- ## Summary by cubic Bumps `speakeasy-core` to v0.24.0 and `speakeasy-client-sdk-go/v3` to v3.28.1. These upgrades expose a platform-issued license token and new `AccessDetails` fields (`license_jwt`, `status_code`), but nothing reads them yet, so CLI behavior is unchanged. <sup>Written for commit 943cae8. Summary will update on new commits.</sup> <a href="https://cubic.dev/pr/speakeasy-api/speakeasy/pull/2126?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->
![https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source](https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source){kind=link}
![https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img](https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img){kind=link}
![https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a](https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a){kind=link}
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
2 participants
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.
Summary
Re-does #2117 (reverted in #2120 after it broke registry auth for customers as v1.795.2):
speakeasy-corev0.22.2 → v0.23.0 — captures the registry license token (the original point of build: bump speakeasy-core to capture the registry license token #2117).speakeasy-client-sdk-go/v3v3.26.7 → v3.28.0 — v3.27.0 was generated from a composed spec that marked all 13 artifacts/subscriptions operationssecurity: [], soutils.PopulateSecurityvanished from them and everytag promote/tag apply/ci tagwent out withoutx-api-key→ 403s. Fixed at the source (speakeasy-registry#4707: fragments now all declare the same top-level security, so merge keeps the global block; #4705 typed thetarget_resourceenum) and regenerated from the registry-published spec (speakeasy-client-sdk-go#52, tagged v3.28.0).PopulateSecurityis back on all 11 Artifacts + 2 Subscriptions operations; the only operations without auth are the three that are public by design (getAccessToken,handleCheckoutCallback,handleStripeWebhook). No SDK signature changes vs v3.26.7.Why no test caught it last time
The regression changed no method signatures — auth just silently disappeared from the requests, so builds and CI stayed green. Registry e2e tests (
TestRegistryFlowetc.) push/pull via oras/ocicommon credentials and never touch the generated SDK; the only SDK-auth callsites areregistry/tagging.go(Artifacts.PostTags) andinternal/remote/sources.go(Artifacts.GetRevisions, which swallows errors entirely) — neither had coverage, and there wasn't a singlehttptestserver in the repo to assert outbound headers.release.ymlruns no tests at all.New regression guards
internal/sdk/sdk_test.go— hermetic contract test:httptestserver +InitSDKWithKey, asserts thex-api-keyheader is present onArtifacts.PostTagsandArtifacts.GetRevisionsrequests. Verified to fail against v3.27.0 (header absent) and pass against v3.26.7 / v3.28.0. Catches any future SDK bump that drops auth, at unit-test speed with no credentials needed.integration/workflow_registry_test.go—TestRegistryFlownow ends withspeakeasy tag promote -s test-source -t e2e-test, exercising the platform-API (SDK) auth path end-to-end alongside the existing oras push/pull. Runs on every PR viavalidate.yml(SPEAKEASY_API_KEY). With v3.27.0 this step 403s.Possible follow-up (out of scope here): a
pkg/mergewarning whensetExplicitNoSecuritystampssecurity: []onto operations, so composed-spec consumers notice before an SDK regen does.Verification (at v3.28.0)
go build ./...,go test ./internal/sdk/pass.go test ./integration/ -run 'TestRegistryFlow$'passes (49s, real platform).