Mike Kistler mikekistler

This is my attempt to get the Traits overlay example working with Speakeasy's overlay tooling.

The original example is here.

Original OpenAPI

openapi: 3.1.0
info:
 title: API with a paged collection

API-ly Ever After: OpenAPI in .NET 9

References

OpenAPI

The PR pipeline checks every PR to determine if it (potentially) introduces breaking changes or violates Azure Versioning policy.

The main tool for this is "openapi-diff" which checks two versions of an OpenAPI doc (old and new) and identifies all the "substantive changes" (changes in descriptions and such are ignored).

Our versioning policy requires that any "substantive change" be done in a new API version.

A subset of the "substantive changes" are also considered a "breaking change"

We add labels to the PR as follows:

IF any change is classified as breaking AND the "old" OpenAPI doc is GA (same or different than new API version)

Proposal for new Breaking Change Labels

Update of proposal from this comment.

Breaking Changes

BreakingChangeReviewRequired

Added by automation when it detects a breaking change from a previous GA API version
Blocks merge until a "BreakingChange-Approved*" label is applied

Resources / relationships for Microsoft DevBox

erDiagram
    Project { 
        string name
    }
    
    Catalog {
 string name

This file describes a proposal for a new design of "links" support for OpenAPI v4 (Moonwalk)

Problems to be solved

There are three key problems with the OpenAPI v3 support for links that this proposal hopes to address:

No support for linking from a full URL

There are some occasions where a response header or body parameter contains a complete URL, e.g. the "Location"

Restler on Databricks (control plane)

This gist will describe how I ran Restler on the Azure Databricks control plane service and the results I obtained.

Clone and build Restler

git clone https://github.com/microsoft/restler-fuzzer.git
restler_bin=~/bin/restler
mkdir -p $restler_bin
# Need --python because it can’t find “python” — I use an alias that it did not understand.

This gist will show how to extract information from the RESTler speccov.json to get a quick view of what operations succeeded and failed in a RESTler run and why.

The primary tool for this is jq.

Here I will use the results of a RESTler test I ran on the Azure DataBricks service.

The test summary reported at the end of the run was:

	string Train(AnomalyDetectorClient client, string dataSource, DateTimeOffset startTime, DateTimeOffset endTime, int maxTryout = 500)
	{
	var modelInfo = new ModelInfo(
	dataSource,
	startTime,
	endTime);

	AnomalyDetectionModel model = client.TrainMultivariateModel(modelInfo);
	var modelId = model.ModelId;

	import { createTypeSpecLibrary } from "@typespec/compiler";
	import { createRule, getLinter } from "@typespec/lint";
	import { isQueryParam } from "@typespec/http";

	export const myLibrary = createTypeSpecLibrary({
	name: "myLibrary",
	diagnostics: {
	"version-policy": {
	severity: "error",
	messages: {