Azure DevOps: User lacks permission to complete this action. You need to have 'AddPackage' - azure-devops

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

Related

Azure pipelines on a self hosted agent gives error NU1301: Unable to load the service index for source during dotnet restore

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.

Failure to restore nuget packages from organisation feed

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.

Use artifact feed from another Project (within same organisation) as upstream source

I have the following setup within a single organisation:
Project A
Feed A (Project scoped)
Project B
Feed B (Project scoped) with upstream sources:
ProjectA.FeedA
nuget.org
For now all packages are added to the Local view, which is the default. And in the Local view permissions, I configured it to 'People in '
When I create a pipeline in ProjectB, that uses the step 'Nuget restore' with feed 'ProjectB.FeedB' I always end with an error while restoring the packages:
Response status code does not indicate success: 502 (Bad Gateway - The upstream source FeedA#Local can't be found because the upstream feed's project with id 'xxxxx-xxxx-xxxx-xxxx-xxxxxxxxx' is deleted or has had its permissions changed. (DevOps Activity ID: XXXXXX-XXXX-XXXX-XXXX-XXXXXX)).)
I figured out that in the past all artifact feeds were 'Organisation scoped'. When creating feeds now, they are 'Project-scoped'. However:
I don't see a way to create an organisation scope feed anywhere (besides using the API).
I don't know how to convert an existing to an organisation scope feed.
If I'm able to configure the view in my Project-Scoped feed to be accessible to the entire organisation I guess this should work?
Any pointers on how to solve this would be very welcome!
I finally figured it out.
Go to
Project settings > Pipeline > Settings
There you can see the option:
Limit job authorization scope to current project
This option is also available in the settings of the organisation!
From the documentation on the topic, it looks like the only way is to use the API, as you said (emphasis mine).
https://learn.microsoft.com/en-us/azure/devops/artifacts/feeds/project-scoped-feeds?view=azure-devops
If you're concerned that your project will be turned public in the
future and you want your feed remain private, you can use the
organization-scoped feed that's automatically created when a new
organization is created. Alternatively, you can use the Create Feed
API to manually create a new organization-scoped feed. You will have
to set the default permissions for the new feed manually either by
using the Feed Permission API or the Artifacts feed settings. Creating
new organization-scoped feeds is not recommended.
So you have two options:
Use the/an existing organisation feed, or
Manually create an organisation feed through the API (not recommended).
However, can you use a special task to authenticate with the project-scoped Azure Artifacts feed before doing your restore? We are currently using a project-scoped feed from one project in another project (within the same organisation) by using the NuGet Authenticate task:
steps:
- task: UseDotNet#2
inputs:
packageType: 'sdk'
version: 3.1.101
- task: NuGetAuthenticate#0
- task: DotNetCoreCLI#2
displayName: 'dotnet restore with nuget.config'
inputs:
command: 'restore'
projects: '**/*.csproj'
feedsToUse: 'config'
nugetConfigPath: 'nuget.config'
I don't see a way to create an organisation scope feed anywhere
(besides using the API).
For this issue ,I am afraid it is not support to create a new organization-scoped feeds through the UI. Currently, only rest API is supported to create feeds for organization scope.
Until now, in our official feature suggestion for Azure Devops forum, there has been a such suggestion exist in it: Organisation scoped feeds. You can comment and vote it there.
If I'm able to configure the view in my Project-Scoped feed to be
accessible to the entire organisation I guess this should work?
For this issue , you can try to add other Project's Build Service groups to the feed permissions in the Permissions of Feed settings.

Azure DevOps Project pipeline not able to access NuGet package from Artifact Feed in different Project

Updated 20-Feb-2020
Summary
Azure DevOps pipeline build not able to find NuGet package from our private feed under Artifacts.
Our Azure DevOps environment
In Azure, we have our company "space": dev.azure.com/OurCompany
Under that, we have multiple Projects, so for example, imagine these three:
Green: this holds applications of a certain type
Blue: this holds applications of a different type
Red: this holds our "common" helper code
RED
RED holds all our common helper code are DLLs consumed by applications in GREEN and BLUE. These are made available as NuGet packages.
Under RED's Artifacts, we see an "organisational scoped feed" called "OurCompany". We understood that we couldn't use this because these NuGet packages need to be available to everyone in OurCompany, which means not only on Azure, but also on our DeskTop machines in our Corporate network (where we run Visual Studio). The "organisational scoped feed" I don't think is exposed to our Corporate Network.
We therefore created a new Feed under RED's Artifacts. When I view Permissions, I see the following entries:
{me} : (Owner)
[OurCompany]\Project Collection Adminstrators : (Owner)
[RED]\Project Administrators : (Owner)
RED Build Service (OurCompany) : (Contributor)
Project Collection Build Service (OurCompany) : (Contributor)
[RED]\Contributors (Contributor)
Corporate
So, back in Corporate, we add the NuGet package feed to our Visual Studio and it can then pull the NuGet packages down from Azure.
GREEN and BLUE
In here we have our products. We create a build Pipeline and we add a NuGet restore step:
- task: NuGetCommand#2
displayName: 'Restore for Our Application'
inputs:
command: 'restore'
restoreSolution: '**/*.sln'
feedsToUse: 'select'
vstsFeed: '{Guid1}/{Guid2}'
The two Guids were filled in when we picket the Azure Artifacts feed from the drop-down.
GREEN or BLUE NuGet Restore Failure
So this is where we run into our issue. When the NuGet restore step executes, it fails with the following message:
Unable to find version 'nnnn.n.n' of package 'TheNuGetPackage'.
The log output is vast, but the salient lines appear to be:
2020-02-18T18:36:35.2838118Z [command]C:\hostedtoolcache\windows\NuGet\5.4.0\x64\nuget.exe sources Add -NonInteractive -Name {Guid2} -Source https://pkgs.dev.azure.com/OurCompany/{Guid1}/_packaging/{Guid2}/nuget/v3/index.json
-ConfigFile d:\a\1\Nuget\tempNuGet_356.config 2020-02-18T18:36:35.7513495Z Package source with Name: {Guid2} added successfully. 2020-02-18T18:36:41.1671856Z [CredentialProvider.183638]Command-line v0.1.20+a5d37185a1a95acb4f0g997b9c23cab99508: "d:\a\_tasks\NuGetCommand_333b11bd-d341-40d9-bdbd-b32d5ce6f23b\2.164.0\CredentialProviderV2\plugins\netfx\CredentialProvider.Microsoft\CredentialProvider.Microsoft.exe"
-Plugin 2020-02-18T18:36:41.1673979Z [CredentialProvider]Handling 'Request' 'GetAuthenticationCredentials'. Time elapsed in ms: 3 - Payload: {"Uri":"https://pkgs.dev.azure.com/OurCompany/{Guid1}/_packaging/{Guid2}/nuget/v3/index.json","IsRetry":false,"IsNonInteractive":true,"CanShowDialog":true} 2020-02-18T18:36:41.1674299Z [CredentialProvider]Handling auth request, Uri: https://pkgs.dev.azure.com/OurCompany/{Guid1}/_packaging/{Guid2}/nuget/v3/index.json, IsRetry: False, IsNonInteractive: True, CanShowDialog: True 2020-02-18T18:36:41.1674465Z [CredentialProvider]URI: https://pkgs.dev.azure.com/OurCompany/{Guid1}/_packaging/{Guid2}/nuget/v3/index.json 2020-02-18T18:36:41.1674818Z [CredentialProvider]Skipping NuGetCredentialProvider.CredentialProviders.VstsBuildTaskServiceEndpoint.VstsBuildTaskServiceEndpointCredentialProvider, cannot provide credentials for https://pkgs.dev.azure.com/OurCompany/{Guid1}/_packaging/{Guid2}/nuget/v3/index.json 2020-02-18T18:36:41.1675261Z [CredentialProvider]VstsBuildTaskCredentialProvider - https://dev.azure.com/OurCompany/ 2020-02-18T18:36:41.1675425Z [CredentialProvider]VstsBuildTaskCredentialProvider - https://pkgs.dev.azure.com/OurCompany/ 2020-02-18T18:36:41.1675722Z [CredentialProvider]VstsBuildTaskCredentialProvider - https://pkgs.dev.azure.com/OurCompany/ 2020-02-18T18:36:41.1676021Z [CredentialProvider]VstsBuildTaskCredentialProvider - https://pkgs.dev.azure.com/OurCompany/ 2020-02-18T18:36:41.1676161Z [CredentialProvider]VstsBuildTaskCredentialProvider - Matched prefix: https://pkgs.dev.azure.com/OurCompany/ 2020-02-18T18:36:41.1676330Z [CredentialProvider]VstsBuildTaskCredentialProvider - Found credentials for endpoint https://pkgs.dev.azure.com/OurCompany/{Guid1}/_packaging/{Guid2}/nuget/v3/index.json 2020-02-18T18:36:41.1680820Z https://pkgs.dev.azure.com/OurCompany/{Guid1}/_packaging/{Guid2}/nuget/v3/index.json: Unable to load the service index for source https://pkgs.dev.azure.com/OurCompany/{Guid1}/_packaging/{Guid2}/nuget/v3/index.json. 2020-02-18T18:36:41.1680996Z Response status code does not indicate success: 404 (Not Found - VS800075: The project with id 'vstfs:///Classification/TeamProject/{Guid1}' does not exist, or you do not have permission to access it. (DevOps Activity ID: 0628EDE7-6E7E-465D-A6AE-7B6B0AA065D2)).
This looks like a permissions thing to me. But what seems odd is that the Artifact Feed in RED was discoverable when creating the Pipeline Build YAML when we then don't have permissions to use it.
I did try adding permissions to the Feed in RED. Clicking on the "Add users/groups". I found the following and added them as either Reader or Contributor, but with no success.
[GREEN]\ Green Team
GREEN Build Services
So:
Am I going about this the wrong way? If so, what ought I be doing (I thought I'd followed the Azure DevOps instructions fairly closely)
Am I going about this the right way? If so, what have I missed?
Update #1
Verbose error message from Restore step
https://api.nuget.org/v3/index.json: Package 'Package1.nnnn.n.n' is
not found on source 'https://api.nuget.org/v3/index.json'.
https://pkgs.dev.azure.com/OurCompany/{Guid1}/_packaging/{Guid2}/nuget/v3/index.json:
Unable to load the service index for source
https://pkgs.dev.azure.com/OurCompany/{Guid1}/_packaging/{Guid2}/nuget/v3/index.json.
Response status code does not indicate success: 404 (Not Found -
VS800075: The project with id
'vstfs:///Classification/TeamProject/{Guid1}' does not exist, or you
do not have permission to access it. (DevOps Activity ID: {Guid})).
Finally, I found the problem. I wonder if this is a bug, or just poorly documented....(or maybe I just didn't interpret it correctly).
As per Leo Lui-MSFT's suggestion above (documented by Microsoft), I'd added the permissions to the NuGet feed, and this didn't work. However, I was intrigued by his sentence:
If you've changed your builds to run at project scope
Personally, I hadn't, so I got with our System Administrator and we went through all the possible settings. Eventually, we found it - it wasn't something I had the ability to change.
So in my example above, BLUE and GREEN are the two projects that are trying to use the NuGet package in RED's Artifact feed.
So picking BLUE (or GREEN), in the bottom left hand corner of Azure DevOps you'll see a link "Project Settings". Under "Pipelines > Settings" there are four settings. We had to change the following to be:
Limit job authorization scope to current project = false
Hope that helps!
Azure DevOps Project pipeline not able to access Artifact Feed in different project
I think you are going the right ways. There is known issue about the project scope feed.
As the document Package permissions in Azure Pipelines stated:
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]) (e.g. FabrikamFiber
Build Service (codesharing-demo))
You could check this thread for some more details.
Hope this helps.
You can do the following to have access to other project feed in the same organization:
Choose the following options from: Feed settings >> Permissions >> [Click on the three-dot menu] >> sel
a) Allow build and releases
b) Allow project-scoped builds
Go to the project settings (from where you want to access the feed)
Make sure the option is unchecked in the following setting: Project Settings >> Pipelines >> Settings >> Limit job authorization scope to current project for non-release pipelines
In my LibsProject I have a LibsFeed (OP's RED), which I wanted to use in a pipeline in my ConsumingProject.
I had to add the following permissions to get it to work:
LibsFeed: Add ConsumingProject Build Service as Contributor (Read automatically changed to Contributor somehow)
LibsProject: Add ConsumingProject Team to the LibsProject Team under LibsProject -> Project Settings -> Team
I can not even enable OP's solution, even with all thinkable admin rights
Limit job authorization scope to current project

Azure Pipelines Hosted Agent Can't Access DevOps project Feed

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.