[savannahostrowski]

During the 3.16.0a1 release, publishing to NuGet timed out after one package had already been uploaded. Retrying the publish failed with a 409 Conflict on that package before reaching the remaining packages, which meant I had to generate a NuGet API key and publish them through the CLI with --skip-duplicate.

This PR adds a NuGet packages to skip on retry field when republishing artifacts from an existing build. It accepts semicolon-separated filenames or wildcard patterns, allowing recovery runs to exclude packages confirmed as already uploaded. The field defaults to (none), so unexpected conflicts still fail normal publishes. The recovery step removes matching packages from the temporary downloaded artifact directory before the existing NuGet task publishes the remaining .nupkg files; the original build artifacts are unchanged.

It also increases the NuGet publish timeout from its default of 300 seconds to 600 seconds and documents the recovery workflow in the README.

Feedback on the PowerShell filtering is welcome! :)

[zooba]

So despite the docs saying that the allowPackageConflicts option is only for private feeds, the implementation seems to support it (provided the error message does actually match what is expected there, I didn't check that).

If we can just enable that option, I'd just do that unconditionally. It keeps things simpler, and if we happen to re-run an existing build, it's going to successfully overwrite other places where it's been published anyway which is messy enough that we are dealing with a mess regardless. Whether or not the build fails silently or loudly doesn't matter much at that point.

[savannahostrowski]

Hm, so I think you’re right that allowPackageConflicts is used for external feeds too. The issue is that the Azure task implementation only ignores the failure when stderr contains The feed already contains.

In the case I ran into, NuGet returned A package with ID 'python-freethreaded' and version '3.16.0-a1' already exists and cannot be modified (see https://dev.azure.com/Python/8e426817-76c0-4b99-ba9e-a48a1e4bd5db/_apis/build/builds/175939/logs/1391), so I don’t think the option would have recognized this conflict?

[zooba]

I don’t think the option would have recognized this conflict?

Probably not.

Here's an alternative to consider - this uses the Nuget API directly to check what versions are already published:

# Get the API root for the Nuget API
$api = ((irm https://api.nuget.org/v3/index.json).resources | ?{ $_.'@type' -eq 'PackageBaseAddress/3.0.0' }).'@id'
# Assume running in directory with files to publish
$to_upload = dir *.nupkg | ?{ $_.BaseName -match '([^.]+)\.(.+)$' } | %{ @{ file=$_; name=$Matches[1]; version=$Matches[2] } }
# Check which ones are already published
$already_present = ($to_upload | ?{ (irm "$api/$($_.name)/index.json").versions -contains $_.version }).file
# Remove them
del $already_present -Verbose
# Upload whatever is left

(I'm mostly fluent in the shortest Powershell shortcuts and didn't expand them, but %{ is Select-Object { and ?{ is Where-Object { or things like that, I'm not sure of the spelling anymore because I always use the short one :D irm is something like Invoke-RestMethod which basically does a HTTP GET and converts from JSON to native objects)