-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stop using the setAuthForSourcesInTempNuGetConfig in all package downloading scenarios, such as nuget install, restore, because it completely breaks PackageSourceMapping #15542
Comments
Collecting all the potentil tasks with issues based on the query:
If I understand it correctly, pretty much any |
Any workarounds for this issue? Would using NuGetAuthenticate negate the need for the addition of the |
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 |
Based on customer feedback, NuGetAuthenticate doesn't negate the issues here: NuGet/Home#11406 (comment) Is this expected? |
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. |
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. |
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 |
Thank you! Please let us know if there's anything we can do to help from NuGet side. |
Hey @magleaso, Any progress on an in-situ fix for the DotnetCLI task? Thanks! |
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. |
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?) |
Hello, I just want to sum up the suggestion by @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 - task: NuGetAuthenticate@1
displayName: 'Authenticate with NuGet'
- task: PowerShell@2
displayName: 'dotnet restore'
inputs:
targetType: 'inline'
script: 'dotnet restore --nologo' |
FWIW, I think it was actually @magleaso's suggestion: #15542 (comment) |
I agree with the goal to deprecate that task... it's always been a bit of a strange one. I would definitely recommend getting some communication out on this though in a larger way. The migration effort for a lot of companies is going to be fairly significant. Early comms on this can help stop the bleeding and reduce the number of migrations. I just luckily happened to stumble on this Github issue and will stop using that task, I can't imagine too many others are going to luck out like I did. |
We still have the same bug using package source mapping |
This issue is stale because it has been open for 180 days with no activity. Remove the stale label or comment on the issue otherwise this will be closed in 5 days |
Would be nice if anyone fixes this issue as it is annoying and time consuming to fix it. I spent three days searching for a solution until I found this issue and noticed a little note at the end of the documentation for Source Mapping that it is not recommended to use the task which is supposed to do the job ( |
The suggestion from Peter-B- is how I was able to make it work, but the pipeline crashes 1 to 2 times a day with this error : Starting: Restore NuGet packages w/PowerShell When it happens, I restart the failed task and it just works. It's annoying and time consuming. |
This issue is stale because it has been open for 180 days with no activity. Remove the stale label or comment on the issue otherwise this will be closed in 5 days |
I haven't tested this recently, but nobody has replied here to say that it's fixed. I think it would still be useful. While Azure Artifacts supports upstream sources, allowing some customers to use nuget.config with a single source, and avoid needing to use Package Source Mapping, it still has a limitation where it only allows other Azure Artifacts feeds from the same org, and nuget.org as upstream sources. The "custom registry" upstream source configuration only allows nodejs feeds, not NuGet. Therefore, if a project needs to use packages across multiple Azure DevOps organization accounts, or a different custom NuGet feed (such as something running on-prem), Azure Artfiacts doesn't provide an alternative to multiple feeds in nuget.config, at which point people might want to use Package Source Mapping. |
I think the DotNetCoreCli task is pretty dead. When I implemented package source mapping, I moved to use the new NugetAuthenticate task and simply call |
Yep, I have also been doing that for years now, the task is too unreliable to use. |
I met this issue recently. I had replace |
The problem with the assumption that using the nugetauthenticate task is always going to be the tool for something like this. What happens if we're doing a build in the docker context where it doesn't have access to nugetauthenticate? |
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]
The text was updated successfully, but these errors were encountered: