Having the same issue on a self hosted agent but I'm not specifying password in the yml. just specifying the vstsFeed
- checkout: self
submodules: true
persistCredentials: true
- task: NuGetToolInstaller#1
inputs:
versionSpec: 6.2.1
- task: UseDotNet#2
displayName: Using Dotnet Version 6.0.400
inputs:
packageType: 'sdk'
version: '6.0.400'
- task: DotNetCoreCLI#2
displayName: Restore Nuget packages
inputs:
command: 'restore'
projects: '**/*.sln'
feedsToUse: 'select'
vstsFeed: 'ba05a72a-c4fd-43a8-9505-a97db9bf4d00/6db9ddb0-5c18-4a24-a985-75924292d079'
and it fails with following error error NU1301: Unable to load the service index for source
Nuget feed is on another project of the same organization. I can see that pipeline produces a temp nuget config where it specifies username and password for this feed during run. Been breaking my head for the last 72 hours non-stop to find what is the issue. Azure pipelines and nuget sucks. 99% of the problems we had so far was with nuget not working smoothly with azure pipelines. Microsoft has to take a step back and resolve pipelines and nuget ssues.
Just to make sure: The NuGet feed is on the same Azure instance as the agent is registered with, right?
I remember similar issues on my on-premise Azure DevOps server, but also sometimes on the paid cloud variant. Sometimes it was flaky service state, sometimes the agent itself..
Kevin did give a good point with the permissions - if those are set, you're good to go from a permissions point of view - actually reader permission is enough for a restore - make sure to check the views panel too.
If after permissions check you still got issues, you might try my "just-making-sure-lines for your .yml file:
# NuGet Authentication (safety step, normally not required as all within the same organization/project)
- task: NuGetAuthenticate#1
displayName: "Nuget Authentication"
It shouldn't be required but I have it on all my pipes since I had such issues, and it reduced the occurence of the error line you posted in my cases (Hybrid devops architecture).
Another thing I ended up with is to specifiy the feeds explicitly in a repository-wide "NuGet.Config" file - and using this file within my yml files or with script lines instead of tasks now.
If nothing helps, enable diagnostics/verbose logging to get more error details. In the worst case: Log in to your agent machine, open a terminal in the same agent work folder and manually issue a dotnet restore command to see whats going on.
Post the additional results if still no progress.
Good luck
From your description, you are using the Nuget feed on another project of the same organization.
You need to check the following points:
Check the permission of the Build Service account.
Here are the steps:
Step1: Navigate to Artifacts ->Target Feed ->Feed Settings -> Permission.
Step2: Grant the Build service account Contributor Role . Build service account name: ProjectnamethePipelinelocated Build Service (Organization name)
For example:
Check the Limit job authorization scope to current project for non-release pipelines option is Enabled in Project Settings -> Settings.
If yes, you need to disable the option and then the pipeline can use the resource outside the project.
Note: To disable this option, you need to disable the option in Organization Settings-> Settings first. Then you could disable the option in Project level.
Related
I am using the following step in my azure-pipelines.yml file:
- task: DotNetCoreCLI#2
displayName: dotnet restore
inputs:
command: restore
projects: '**/*.csproj'
feedsToUse: 'select'
vstsFeed: 'TEC-Get'
includeNuGetOrg: true
Unfortunately this fails with the following error on running the pipeline:
C:\Program Files\dotnet\sdk\5.0.201\NuGet.targets(131,5): error : Response status code does not indicate success: 403 (Forbidden - User 'b55d7ea1-921b-49df-87fe-761c8c8988d0' lacks permission to complete this action. You need to have 'ReadPackages'. (DevOps Activity ID: 59D1A1DF-6300-427C-9BAA-16A2FA5EF74E)). [D:\a\1\s\Common\Common.csproj]
GET https://api.nuget.org/v3-flatcontainer/system.security.cryptography.protecteddata/index.json
NuGet.Protocol.Core.Types.FatalProtocolException: Unable to load the service index for source https://pkgs.dev.azure.com/TEC007/_packaging/TEC-Get/nuget/v3/index.json.
From the error it is clear I need to grant permission to a user, but I don't know how I can tell which one it is within my organisation.
Can anyone help with this please?
Thanks.
In the Azure DevOps pipeline, it restore the package via service account instead of personal account. Check this doc: Package permissions in Azure Pipelines
To use packages from a feed in Azure Pipelines, the appropriate build identity must have permission to your feed. By default, the Project Collection Build Service is a Contributor. If you've changed your builds to run at project scope, you'll need to add the project-level build identity as a Reader or Contributor, as desired. The project-level build identity is named as follows: [Project name] Build Service ([Organization name])
We could also do this via click the button Allow project-scoped builds, check the pic below.
I'm trying to set up a simple CI pipeline in Azure Devops
I have found it super easy to to do a Build -> Publish from within VS2019 to an Azure App Service, and it works flawlessly.
However, when trying to set up a CI pipeline which does the exact same thing from Azure Devops, I am presented with a YAML file, and options which I can drop into it.
I managed to get my pipeline to reach the "build" part, but then it couldn't find my custom nuget feed, so I updated my yaml to include this nuget restore:
trigger:
- master
pool:
vmImage: 'ubuntu-latest'
variables:
buildConfiguration: 'Release'
steps:
- task: NuGetCommand#2
inputs:
command: 'restore'
restoreSolution: '**/*.sln'
feedsToUse: 'select'
vstsFeed: 'feed-id'
- script: dotnet build --configuration $(buildConfiguration)
displayName: 'dotnet build $(buildConfiguration)'
But the build fails again, with this error:
##[error]The nuget command failed with exit code(1) and error(Unable to load the service index for source https://MYVSTSADDRESS.pkgs.visualstudio.com/_packaging/THE_GUID/nuget/v3/index.json.
My question is, can't I just import the exact process that I follow from vs 2019?
Why is it so annoyingly complicated to do the exact same thing from devops?
Why would I need to complete this YAML document in devops, if its not required from VS??
##[error]The nuget command failed with exit code(1) and error(Unable to load the service index for source https://MYVSTSADDRESS.pkgs.visualstudio.com/_packaging/THE_GUID/nuget/v3/index.json.
From the URL in the error message, it seems that the task is using the Organization Scope Feed.
Based on my test, some pipeline settings will affect the use of this feed.
First, please check if your error message is similar to the following：
If yes, you could check the Limit job authorization scope to current project for non-release pipelines option is Enabled in Project Settings -> Pipelines.
You could try to disable the option.
Note: To disable this option, you need to disable the option in Organization Settings-> Settings first. Then you could disable the option in Project level.
Then you could navigate to Artifacts -> Feed Settings -> Permissions->... to enable the option Allow Project-Scoped builds.
I get an error:
User XXX lacks permission to complete this action. You need to have 'AddPackage'
when trying to push a nuget package to Azure DevOps artifacts. I am the administrator
This is the stage:
- stage:
displayName: 'Release'
condition: succeeded()
jobs:
- job: 'Publish'
displayName: 'Publish nuGet Package'
steps:
- download: current
artifact: $(PIPELINE_ARTIFACT_NAME)
displayName: 'Download pipeline artifact'
- script: ls $(PATH_PIPELINE_ARTIFACT_NAME)
displayName: 'Display contents of downloaded articacts path'
- task: NuGetAuthenticate#0
displayName: 'Authenticate in NuGet feed'
- script: dotnet nuget push $(PATH_PIPELINE_ARTIFACT_NAME)/**/*.nupkg --source $(NUGET_FEED) --api-key $(NUGET_API_KEY)
displayName: 'Uploads nuGet packages'
And the exact error:
error: Response status code does not indicate success: 403 (Forbidden - User '4a2eb786-540d-4690-a12b-013aec2c86e5' lacks permission to complete this action. You need to have 'AddPackage'. (DevOps Activity ID: XXXXXXX-6DF9-4A98-8A4E-42C556C6FC56)).
##[error]Bash exited with code '1'.
Finishing: Uploads nuGet packages
The git repo is in GitHub. Not sure who is considered to be the user but I don't know which other permissions to modify
It seems I fixed by adding to the feed's permission settings the Build Service as Contributor.
It's a bit confusing tbh but it's now working fine.
Steps:
Click on Artifacts on the left side.
Select your feed from the drop down (usually selected by default)
Click the Feed Setting gear on the top right corner.
Click Permissions
Click Add Users/groups and search for {your org} Build Service and add as Contributor.
For those who are completely lost like me, the page mentioned by #diegosasw is in the Artifacts menu, not in the Task or in the Pipeline:
A few things have changed in at least the Azure Devops web interface as of 2022-07. Although the fundamentals appear unchanged, the ... button talked about earlier is gone. Below are the steps I figured at the time of writing. Extracted from a bit of a whinging blog post, which has more details and context.
Create a new feed, setting the scope to the project:
By default, the permission list created for the new feed is as below. Note that the organisation_name Build Service (project_name) user or group has the role Collaborator by default. This may be the key stumbling block users trip over.
You cannot change the role; you have to remove the organisation_name Build Service (project_name) user or group and add it again with the Contributor role.
Great find! Allowing project-scoped builds in the ... menu worked for me.
But in order to be able to push the package from Azure Pipelines to the Azure Artifacts feed at all, I had to add the same feed as Target feed under the dotnet restore step before dotnet build and finally dotnet push. https://learn.microsoft.com/en-us/azure/devops/artifacts/nuget/dotnet-exe?view=azure-devops
My solution was slightly different. New pipelines default to "Current Project" under Pipeline > Edit > Options > Build job > Buld job authorization scope.... this needed changing to "Project collection", which solved the problem:
the correct answer is, at the artifact settings page (you can access following the explanation above) you need to add contributor permission to the user with the name pattern [project_name] Build Service. For example, if your project name is "IoT" you need to find the user "IoT Build Service" at the Add user/groups in the permission tab as shown above and assign the contributor permission.
See ArkadiuszKozie-6872's answer here:
https://learn.microsoft.com/en-us/answers/questions/723164/granting-read-privileges-to-azure-artifact-feed.html
Had to grant Contributor to Project Collection Build Service (<YOUR-ORG-NAME>) too, which fixed it for me.
If you still got the error, you could try to add the Team as Contributor as well.
Hope it works.
[project_name][project_name] Team - Contributor
project_name Build Service(Org_name) - Contributor
I had the exact problem. Under Feed Settings -> Permissions I could locate the Project Collection Build Service (Organization) with the Contributor permissions but did not work. As a solution I removed that and added "Project Name" Build Service (Organization). This is the build service for the project on which I have created the pipeline specifically.
Just a note - make sure you put your Build Service as Contributor.
I had mine as Collaborator which is a completely different role and I didn't notice the difference since they just appear very similar.
Just an extra information when using "Project Name" Build Service (Organization), even of the search does not return any result, the save button becomes enabled if the name is correct
I have an Azure DevOps project (just one).
I have a Build Pipeline set to run in the "Hosted VS2017" Agent Pool. This Agent Pool appears to be in the [MyProject]\Build Administrators, Contributors, Project Administrators, and Release Administrators roles.
I also have an Artifacts nuget feed in the DevOps project. It has [MyProject]\Project Valid Users set as "Reader" role. It appears that Project Valid Users has all of the Agent Pool's roles mentioned above as members.
I have an azure-pipelines.yml script that adds that adds the artifacts feed as a nuget source right at the beginning:
# Add nuget source
- powershell: Invoke-RestMethod "https://dist.nuget.org/win-x86-commandline/latest/nuget.exe" -OutFile "$env:UserProfile/nuget.exe"
- script: '%UserProfile%\nuget.exe sources Add -Name "devops" -Source "https://pkgs.dev.azure.com/MyProject/_packaging/feed/nuget/v3/index.json"'
The build yml then dot a dotnet build but fails inside NuGet.targets with:
Unable to load the service index for source https://pkgs.dev.azure.com/MyProject/_packaging/feed/nuget/v3/index.json.
Response status code does not indicate success: 401 (Unauthorized).
how can I make this work? My build needs packages from other builds that are on that artifacts feed...
There is a better alternative imo. You can continue using your script to dotnet restore.
Simply add a task just before that with NuGetAuthenticate#0
steps:
- task: NuGetAuthenticate#0
- script: dotnet restore --no-cache --force
this task will authenticate the pipeline with the nuget feeds that require so and are found at the NuGet.config file.
More info here
Notice that when the nuGet feed is within Azure DevOps there is nothing else required. If the feed is external you can configure at your Azure DevOps a nuGet Service Connections (at the link there is further info).
Use the built-in tasks for installing and running NuGet and you won't have authentication problems.
Use the dotnet task's restore command. If you're using a single Azure Artifacts feed, just select it from the dropdown in the task (instead of the PowerShell you mentioned). If multiple feeds (doesn't look like it from your question, but just in case), you'll need to check in a NuGet.config that references all of those feeds, then point the task to that config.
You may also need to pass the '--no-restore' flag to your 'dotnet build' command.
If you still encounter issues, ensure the correct build identity has access to your feed.
We are building CD pipeline using VSTS hosted build servers. It takes more than 3 minutes to restore Nuget. This is too much time.
How can I make it run faster? Is there any sort of caching system we can use?
UPDATE: Caching is now generally available (docs)
Caching is currently on the feature pipeline with a TBD date. In the mean time you can use the Upload Pipeline Artifact/Download Pipeline Artifact tasks to store results in your Azure DevOps account to speed up up/downloads.
The Work-in-progress can be tracked here.
In the mean time, the Microsoft 1ES (one engineering system, internal organization) has released their internal solution that uses Universal Packages to store arbitrary packages in your Azure DevOps account. It's very fast because it can sync the delta between previous packages. There is a sample on how to configure your Azure Pipeline to store the NuGet package cache in your Sources Directory in order for the task to cache them.
variables:
NUGET_PACKAGES: $(Build.SourcesDirectory)/packages
keyfile: '**/*.csproj, **/packages.config, salt.txt'
vstsFeed: 'feed name'
steps:
- task: 1ESLighthouseEng.PipelineArtifactCaching.RestoreCache#1
displayName: 'Restore artifact'
inputs:
keyfile: $(keyfile)
targetfolder: $(NUGET_PACKAGES)
vstsFeed: $(vstsFeed)
In my scenario, Nuget restore ran quickly when run interactively, but very slowly when run through CD pipeline (Jenkins). Setting revocation check mode to offline reduced my Nuget restore times from 13+ minutes to under 30 seconds (I found this solution here)
I set an environment variable in my build script prior to running Nuget restore:
SET NUGET_CERT_REVOCATION_MODE=offline
Disclaimer: Turning off certificate revocation has implications - see this link.