[BUG] Publisher not throwing error in GA workflows when connectivity is not available

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.

MIT License

328 stars 193 forks source link

Release version

v6.0.1.1

Describe the bug

When publisher run for the artifacts having named values attached to Azure Keyvault, during publisher run if AKV is not accessible or have no proper rights ADO throws an error clearly stating the same but GA doesn't fail and go ahead without any error.

Expected behavior

GA also should fail when there is no Access to the respective resource like ADO does.

Actual behavior

GA does not fail when connectivity is not available and logs says it has put the named values in APIM but actually it is not created. At the same time ADO works fine and give proper error.

Reproduction Steps

Create an api has reference to namedvalue which holds the value from the Keyvault.
Deploy to another instance which does not have access to the Kwyvault.
Run publisher.
In GA you can see it will not fail for the named value but fail when it will try to setup the policy as named value object is not created and it is trying to refer the same. And when you run the same using ADO it will fail at the stage of named value creation itself.

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.

Azure / apiops