[BUG]Empty serviceUrl Causing Deployment Failures

[ehalas]

Release version

v6.0.1.4

Describe the bug

The extraction process is including "serviceUrl": "", which disrupts API deployment during critical situations or version rollback when utilizing the current version.

{"code":"ValidationError","target":"ServiceUrl","message":"The field serviceUrl is invalid."}]}

Expected behavior

The extraction process should disregard "serviceUrl" when it is empty, as the value is considered invalid for publisher (and the field is not mandatory).

Actual behavior

Error when trying to publish the same code extract from production environment. {"code":"ValidationError","target":"ServiceUrl","message":"The field serviceUrl is invalid."}]}

Reproduction Steps

Extract an API without a serviceUrl value, and attempt to publish any adjustment with this code.

[github-actions[bot]]

  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]

@waelkdouh and @guythetechie , I can confirm this is an issue. You can get around the validation error by removing the serviceUrl completely (which is what happens when you delete it in the portal and run the extractor), but if you remove the serviceUrl it looks like the APIM base url is getting put back into the serviceUrl similar to the issue we had a while ago: #275

I was not able to find any work arounds to this issue other than populating the serviceUrl with some dummy value as I would speculate the use case for this is setting a backend in a policy instead of using the serviceUrl.

[guythetechie]

Thanks for investigating, @anotherRedbeard. It seems more of an APIM issue than an ApiOps issue. What are your thoughts on how best to handle this? Remove the serviceUrl? Populate it with a dummy value?