Azure / apiops

APIOps applies the concepts of GitOps and DevOps to API deployment. By using practices from these two methodologies, APIOps can enable everyone involved in the lifecycle of API design, development, and deployment with self-service and automated tools to ensure the quality of the specifications and APIs that they’re building.
https://azure.github.io/apiops
MIT License
327 stars 192 forks source link

Running publisher with an API that has a VersionSet fails on an 'empty' APIM instance #641

Open anotherRedbeard opened 2 months ago

anotherRedbeard commented 2 months ago

Release version

v6.0.1.1

Describe the bug

When I run the publisher to upload all of my artifacts (one of the apis contains a versionSet into a 'clean' apim instance I get the following error stating that the ApiVersionSet not found.

System.Net.Http.HttpRequestException: HTTP request to URI <service_url> failed with status code 404. Content is '{"error":{"code":"ResourceNotFound","message":"ApiVersionSet not found.","details":null}}'

Expected behavior

Publisher would create the API with multiple versions correctly into APIM.

Actual behavior

Error occurs trying to find the versionSet that is stored in the apiinformation.json file. Since it's an empty APIM instance it won't find the versionSet.

Reproduction Steps

github-actions[bot] commented 2 months ago
  Thank you for opening this issue! Please be patient while we will look into it and get back to you as this is an open source project. In the meantime make sure you take a look at the [closed issues](https://github.com/Azure/apiops/issues?q=is%3Aissue+is%3Aclosed) in case your question has already been answered. Don't forget to provide any additional information if needed (e.g. scrubbed logs, detailed feature requests,etc.).
  Whenever it's feasible, please don't hesitate to send a Pull Request (PR) our way. We'd greatly appreciate it, and we'll gladly assess and incorporate your changes.
anotherRedbeard commented 2 months ago

One workaound for this is to create a new version set using the API with the same id that is saved in your artifacts folder under the version sets folder.

guythetechie commented 2 months ago

@anotherRedbeard - when you run the extractor, the apiVersionSetId property in your apiInformation.json has the full resource ID of your version set. That resource ID maps to your original APIM instance: /subscriptions/.../service/your-source-instance/apiVersionSets/...

When the publisher runs in your destination, it tries to assign the API to that version set ID. Since the version set ID points to your source instance, it fails.

I can think of two options:

  1. Change the apiVersionSetId property in your apiInformation.json to from /subscriptions/.../apiVersionSets/your-version-set-name/ to just /apiVersionSets/your-version-set-name. When the publisher runs, it will look for the version set in the destination instance. The downside here is that the extractor will overwrite this whenever you run it.
  2. In your publisher configuration override, set properties.apiVersionSetId for your API to /apiVersionSets/your-version-set-name.

There are several resources that have this unfortunate behavior: the REST API returns the full resource ID pointing to the source instance. The fix is to override or update the property and remove /subscriptions/your-subscription-id/resourceGroups/your-resource-group-name/providers/Microsoft.ApiManagement/service/your-service-name from the resource ID.