Preview builds

ProAvailable on Pro and EnterprisePreview builds are unlimited.

Preview builds answer "what will this spec change do to the SDK?" before anyone merges. When a pull request in the spec's repository touches the spec path, typeship generates from the PR's head, diffs the API surface against the base branch, and reports on the PR itself.

Preview builds need a repository source. They run on opened, synchronize, reopened, and ready_for_review.

What lands on the pull request

One sticky comment, updated on every push:

• The verdict up top: No breaking changes if this PR merges. or 2 breaking changes if this PR merges.
• Added: new methods.
• Removed (breaking): methods that disappear.
• Changed: per method, what changed, with breaking changes marked: a parameter that became required, a type that changed, a field that was removed, a return type or pagination shape that changed.
• New warnings and Resolved warnings, so a spec fix that clears a warning shows up as progress.
• A link to the full generated package in the console.

A commit status named typeship/preview. It is success when the change is additive and failure when it removes methods, changes types, makes inputs required, or when the head spec fails to generate. Make it a required check to block breaking merges, or leave it advisory.

What counts as breaking

• A method removed.
• A parameter or body field added as required.
• A parameter, body field, or return type whose type changed.
• A parameter or field that became required.
• A parameter or field removed.
• Pagination detected differently.

Additions with optional inputs, and changes to an operation's HTTP method or path that keep the same method name, are reported as changes but not marked breaking.

Before merge and after

Preview builds are the gate: they run on the spec repository, before the change exists anywhere else, which is the only moment a breaking change is still cheap to avoid. The regeneration pull request that follows a merge carries the other half, a typeship/semver status and a breaking label in each destination, so the SDK's version honors what changed. See Breaking changes. A project with a URL source gets the second half only.

Details

• Spec patches apply to both sides of the diff, so the comment reflects the spec change, not the patches.
• The preview package is generated for TypeScript with the project's platforms.
• Preview generations appear in the project's history with the preview trigger and do not count against the hosted generation allowance.
• If the PR does not change the spec's content, no comment is posted.