Tracking Request IDs across Collection generator executions.

[kevinswiber]

Postman users/customers are looking to integrate the generated output from the openapi2postmanv2 CLI in their CI/CD pipelines.

This works well and good.

However, a workflow that's gaining usage is to maintain a pristine copy of a Postman Collection that maps directly the OpenAPI definition. Changes happen inside Postman only through forks of this Collection. Updates to the pristine Collection only flow from source control to Postman via the Postman API (or postmanctl). After the upsert into Postman, forks can then pull in upstream changes, merging conflicts as they do.

Now, this is where it becomes problematic.

There's no persistence of Request IDs between generator executions. Because of this, Postman's semantic diff, when merging changes, interprets that all the previous Requests have been deleted and that the upstream collection now only has brand new Requests.

What I'd like to do is have an option to output a "source map" of sorts (though much simpler) that maps a JSON Ref of an OpenAPI operation to a previously generated Request ID.

This "source map" can then be used on subsequent generator executions. If a Request ID exists, it can use the one provided. Otherwise, it can use the built-in Request ID generation that happens through the Collection SDK.

I'm curious if there's any interest in adding this to the project directly. Otherwise, I can just work on a fork. Also, I'm curious if there are any implementations snags that anyone foresees.

Thanks!