Fix NuGet.org base URL default, improve API integration #813
+322
−39
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation and Context
This resolves #738. There are two issues with the NuGet.org integration today:
registryBaseUrlfor NuGet tohttps://api.nuget.org/v3/index.json.https://api.nuget.orgis not the entry point for our service and is not specific enough.https://api.nuget.org/v3/index.jsonis the value that users put into their tooling to connect to our public registry (it is installed by default in .NET client tooling).registryBaseUrl) is, however.Additionally, I polished up the error messages so various error modes are clearer. When packages are published to NuGet.org, they take 2-5 minutes to become available due to validations we run.
Some possible states that are now handled and described more helpfully are:
There are only 3 authors (me, another MSFT person, and a community member) explicitly setting the old value. The DB migration will fix the issue. A future publish will fail with the validation error but the error message is clear.
registry type and base URL do not match: 'https://api.nuget.org' is not valid for registry type 'nuget'. Expected: https://api.nuget.org/v3/index.jsonHow Has This Been Tested?
docker compose up, confirm the migration updates the specific packageBreaking Changes
Yes, but minimal impact expected, unless there is a dependency on the specific
https://api.nuget.orgvalue downstream. I am not aware of any such dependency, and the new value is more proper and specific.Types of changes
Checklist
Additional context
For more information about the NuGet API see: https://learn.microsoft.com/en-us/nuget/api/overview#service-index (I wrote most of the docs).