Skip to content

Enable allow externally-sourced versions on upstreamed version #805

Description

@marcpopMSFT

The dotnet-workload feed we typically publish to has dotnet-public as an upstream. This causes problems for any packages that are only available in dotnet-public as the nuget apis will detect the package is available in dotnet-workloads, try to download it, and fail if the allow external sourced versions setting isn't enabled (which isn't not by default and not for any of these packages).

We can't just publish the same package to dotnet-workloads as the nuget api doesn't let us.

Here are two attempts to publish that both failed because of this:
https://dev.azure.com/dnceng/internal/_build/results?buildId=2967946&view=results
https://dev.azure.com/dnceng/internal/_build/results?buildId=2967926&view=results

error: Response status code does not indicate success: 409 (Conflict - 'Microsoft.MacCatalyst.Ref.net9.0_26.4 26.4.9015' cannot be published to the feed because it exists in at least one of the feed's upstream sources. Publishing this copy would prevent you from using 'Microsoft.MacCatalyst.Ref.net9.0_26.4 26.4.9015' from 'dotnet-public@Local'. For more information, see https://go.microsoft.com/fwlink/?linkid=864880 (DevOps Activity ID: 2956A49E-1901-4179-8AC0-41751F61E5E1)).

What we need to do is catch this particular error and then try setting the setting that allows upstream packages to be downloaded:
https://learn.microsoft.com/en-us/azure/devops/artifacts/concepts/upstream-behavior?view=azure-devops#allow-external-versions-using-the-rest-api

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions