Stop using the setAuthForSourcesInTempNuGetConfig in all package downloading scenarios, such as nuget install, restore, because it completely breaks PackageSourceMapping

[nkolev92]

Note

Issues in this repo are for tracking bugs, feature requests and questions for the tasks in this repo

For a list:
https://github.com/Microsoft/azure-pipelines-tasks/tree/master/Tasks

If you have an issue or request for the Azure Pipelines service, use developer community instead:

https://developercommunity.visualstudio.com/spaces/21/index.html )

Required Information

Entering this information will route you directly to the right team and expedite traction.

Question, Bug, or Feature?
Type: Bug

Enter Task Name: Tasks/DotNetCoreCLIV2/restorecommand.ts, but really all commands in this list
https://github.com/microsoft/azure-pipelines-tasks/search?q=setAuthForSourcesInTempNuGetConfig

list here (V# not needed):
https://github.com/Microsoft/azure-pipelines-tasks/tree/master/Tasks

Environment

• Server - Azure Pipelines or TFS on-premises?

  • If using TFS on-premises, provide the version: N/A

  • If using Azure Pipelines, provide the account name, team project name, build definition name/build number: N/A

• Agent - Hosted or Private:

  • If using Hosted agent, provide agent queue name: N/A

  • If using private agent, provide the OS of the machine running the agent and the agent version: N/A

Issue Description

[Include task name(s), screenshots and any other relevant details]

NuGet recently release a supply chain feature called PackageSourceMapping.
That feature uses the package source keys from a NuGet.Config.

See details here: https://devblogs.microsoft.com/nuget/introducing-package-source-mapping/ and https://docs.microsoft.com/en-us/nuget/consume-packages/package-source-mapping.

https://docs.microsoft.com/en-us/nuget/consume-packages/package-source-mapping#enabling-package-source-mapping

Azure DevOps has many tasks that rewrite the config and add a feed- prefix, but unfortunately this breaks all source mapping configurations.

See NuGet/Home#11406

Please stop relying on rewriting the nuget.config for these operations.

Task logs

https://github.com/microsoft/azure-pipelines-tasks/search?q=setAuthForSourcesInTempNuGetConfig

[Enable debug logging and please provide the zip file containing all the logs for a speedy resolution]

Troubleshooting

Checkout how to troubleshoot failures and collect debug logs: https://docs.microsoft.com/en-us/vsts/build-release/actions/troubleshooting

Error logs

[Insert error from the logs here for a quick overview]

[nkolev92]

Collecting all the potentil tasks with issues based on the query:

• https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/build/dotnet-core-cli?view=azure-devops
  • push - it doesn't really use package source mapping, but it'd be nice to go away from this completely.
  • restore - This is the biggest problem, as this is the core target.
• DownloadGitHubNugetPackageV1 - it has no docs afaik
  • Restore command
• https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/package/nuget?view=azure-devops
  • restore
  • Unsure what nugetpublisher, but that also uses that code.

If I understand it correctly, pretty much any dotnet restore or nuget.exe restore command would have issues.

[nkolev92]

Any workarounds for this issue?

Would using NuGetAuthenticate negate the need for the addition of the feed- and a PAT?
Is that a workaround for customers facing this issue?

[magleaso]

Yes, the NuGet Authenticate is what we recommend using for all scenarios going forward. We're in the process of deprecating the heavyweight NuGet command task and its equivalent in other protocols including dotnet

[nkolev92]

Based on customer feedback, NuGetAuthenticate doesn't negate the issues here: NuGet/Home#11406 (comment)

Is this expected?

[magleaso]

Responded there. The user has a misunderstanding of how the authenticate task is supposed to be used. It only handles authentication and should then be followed by a command line invocation of the standard CLI client. Any bad behavior at that point is bad behavior in the standard client, not any code that was written in a pipeline task.

[nkolev92]

Do you think there's something that can be done about how changing the tasks behavior to not change up the config?

My concern is that the errors customers would hit are difficult to diagnose.

[magleaso]

Our team is still discussing internally how we'll handle this. We are trying to discontinue any work on the heavyweight tasks and encourage adoption of the authenticate tasks

[nkolev92]

Thank you!

Please let us know if there's anything we can do to help from NuGet side.

fyi Arturo Ortiz (@aortiz-msft) Jon Douglas (@JonDouglas)

[nkolev92]

Hey magleaso,

Any progress on an in-situ fix for the DotnetCLI task?

Thanks!

[magleaso]

No, but I can tell you the outcome where we patch the DotnetCLI task, if it does happen, will still take further time. For the time being, the solution is to use the authenticate task.

[ransagy]

Just to be clear - Are we saying people should, in general, not ever use DotNetCoreCLIV2 task anymore and replace it by cmd/bash/pwsh calls? (and maybe NuGetV0/NuGetCommandV2? others?)

[Peter-B-]

Hello,

I just want to sum up the suggestion by Nikolche Kolev (@nkolev92) for reference:

Replace the normal dotnet restore task

- task: DotNetCoreCLI@2
  displayName: dotnet restore
  inputs:
    command: 'restore'
    restoreArguments: '--nologo'
    feedsToUse: 'config'
    nugetConfigPath: 'Nuget.config'
    verbosityRestore: 'Normal'

with a separate Nuget authenticate and a Powershell dotnet restore task:

- task: NuGetAuthenticate@1
  displayName: 'Authenticate with NuGet'

- task: PowerShell@2
  displayName: 'dotnet restore'
  inputs:
    targetType: 'inline'
    script: 'dotnet restore --nologo'