I have an azure devops yaml pipeline in project A trying to download an artifact in project B within the same organization. It uses the DownloadBuildArtifacts#0 task as configured below:
- task: DownloadBuildArtifacts#0
inputs:
buildType: 'specific'
project: 'f0a63c0e-a678-44ea-92f4-490def403add'
pipeline: '38'
buildVersionToDownload: 'latest'
downloadType: 'single'
artifactName: 'drop'
downloadPath: '$(System.ArtifactsDirectory)/Common'
Where 'f0a63c0e-a678-44ea-92f4-490def403add' is the project id of Project B and 38 is the build pipeline defintion id producing the artifact in Project B. This works fine when executed in a pipeline within Project B. But fails with error below when I try to run the same task from a pipeline in Project A.
##[error]Failed in getBuildId with error: Error: VS800075: The project with id 'vstfs:///Classification/TeamProject/f0a63c0e-a678-44ea-92f4-490def403add' does not exist, or you do not have permission to access it.
##[error]Error: VS800075: The project with id 'vstfs:///Classification/TeamProject/f0a63c0e-a678-44ea-92f4-490def403add' does not exist, or you do not have permission to access it.
Finishing: DownloadBuildArtifacts
It looks like Project A has no access to Project B. Where and how do I set these permissions?
UPDATE:
I checked "Limit job authorization scope to current project" option as advised in this post https://github.com/MicrosoftDocs/azure-devops-docs/issues/6790 but it was disabled. So not sure what other settings are needed.
Actually the option "Limit job authorization scope to current project" as explain in this post is the answer https://github.com/MicrosoftDocs/azure-devops-docs/issues/6790. I was just disabling it in one of the pipelines. As soon as I set it in both pipelines it started working. FYI The same setting option exists at the organization level.
Related
I have an Azure DevOps pipeline step failing running the OWASP dependency check. I want to find what dependencies need to be updated.
The logs that are written during the dependency check pipeline step say:
[INFO] Writing report to: e:\vsts\a\7567\TestResults\dependency-check\dependency-check-report.html
I assume this dependency-check-report.html is where it will tell me what dependencies need to be updated. But I do not understand where this e:\vsts\a\7567\TestResults\ location is, as this step is being run in DevOps. Is this somewhere in DevOps? I cannot seem to find it anywhere. "Download logs" on the pipeline page doesn't seem to have it either.
where this e:\vsts\a\7567\TestResults\ location is
When you run the pipeline in Azure DevOps, this path represents the local path of the machine where the agent locates.
In your case, the agent is self-hosted agent. You go to the local machine where the agent locates and find the dependency-check-report.html in e:\vsts\a\7567\TestResults\dependency-check.
On the other hand, you can use the Publish Pipeline Artifacts task to upload the target file to Pipeline artifacts.
For example:
steps:
- task: dependency-check-build-task#6
displayName: 'Dependency Check'
inputs:
projectName: test
scanPath: test
continueOnError: true
- task: PublishPipelineArtifact#1
displayName: 'Publish Pipeline Artifact'
inputs:
targetPath: '$(Common.TestResultsDirectory)'
artifact: drop
Note: You need to set the continueOnError: true in OWASP dependency check task.
In this case, the dependency-check-report.html on agent machine will be uploaded to Azure Artifacts.
For example:
I am switching our pipelines from using on-prem build agent pool to a Hybrid Activation build agent (on-prem server with SSM Agent installed).
I am hitting a small issue when building our artefact. Our build pipeline does not seem to be able to publish the build artefact to the below File Share path on the new agent pool:
\\vwcnexstore08.comp.internal.corp\tfs_scm_drop\BuildDrops\$(System.TeamProject)\$(Build.DefinitionName)\$(Build.BuildNumber)
I am getting this error when I run the build:
Publishing build artifacts failed with an error: Unable to create directory '\\vwcnexstore08.comp.internal.corp\tfs_scm_drop\BuildDrops\CarEvaluator\CarEvaluator (dev branch)\CarEvaluator (dev
branch)_2.0.0293\drop'.
Unable to verify the directory exists: '\\vwcnexstore08.comp.internal.corp\tfs_scm_drop\BuildDrops\CarEvaluator\CarEvaluator (dev branch)\CarEvaluator (dev branch)_2.0.0293\drop'.
If directory is a file share, please verify the share name is correct, the share is online, and the current process has permission to access the share.
This is my PublishBuildArtifacts task
steps:
- task: PublishBuildArtifacts#1
displayName: 'Publish Artifact'
inputs:
PathtoPublish: '$(build.artifactstagingdirectory)'
ArtifactName: '$(Parameters.ArtifactName)'
publishLocation: FilePath
TargetPath: '\\vwcnexstore08.comp.internal.corp\tfs_scm_drop\BuildDrops\$(System.TeamProject)\$(Build.DefinitionName)\$(Build.BuildNumber)'
Note: The above used to work fine with the previous Agent pool
Could someone please share what I am doing wrong?
Unable to publish to File Share in Azure build pipeline
According to the document Publish Build Artifacts task:
The path must be a fully-qualified path or a valid path relative to the root directory of your repository.
So, you should make sure the TargetPath could be access on your on-prem server.
On the other hand, if the TargetPath is not share for everyone, the project build service account (“BuildService (orgname)”) is in the whitelist for access.
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.
This is an ASP.NET Core 3.0 project that builds with no errors, but when it triggers the pipeline to release to Azure App Service, it fails with the following error:
2019-11-10T23:09:23.8008460Z ##[error]Error: No package found with specified pattern: D:\a\r1\a***.zip
What needs to be done to fix the release pipeline? The pipeline release is pulling the latest build as its artifact.
Assumptions
The following info assumes that you are appropriately publishing your build artifact from your Build pipeline, and that you have added the correct build artifact into you release pipeline.
In your release pipeline you have specified a build artifact in the Artifacts area
When adding your build artifact to your release pipeline, you chose to give it an alias of Build Artifact. This means that at the very lease (with default settings) your .zip file will be in some sub-directory of $(system.DefaultWorkingDirectory)/Build Artifact/
A new unique folder in the agent is created for every release pipeline when you initiate a release, and the artifacts are downloaded into that folder. The $(System.DefaultWorkingDirectory) variable maps to this folder.
To ensure the uniqueness of every artifact download, each artifact source linked to a release pipeline is automatically provided with a specific download location known as the source alias. This location can be accessed through the variable:
$(System.DefaultWorkingDirectory)\[source alias]
This uniqueness also ensures that, if you later rename a linked artifact source in its original location (for example, rename a build pipeline in Azure Pipelines or a project in Jenkins), you don't need to edit the task properties because the download location defined in the agent does not change.
The source alias is, by default, the name of the source selected when you linked the artifact source, prefixed with an underscore; depending on the type of the artifact source this will be the name of the build pipeline, job, project, or repository. You can edit the source alias from the artifacts tab of a release pipeline; for example, when you change the name of the build pipeline and you want to use a source alias that reflects the name of the build pipeline.
(from some of the abundant documentation
Instead of searching for your package using ***.zip (which isn't proper wildcard syntax) use Build Artifact/**/*.zip
** is for recursively searching into directories
(I don't know what folder)
* is for searching a part of a given level of the path
any file/folder that
starts with (SomeFile.*)
ends with (*File.zip)
and i think contains (*meFi*)
The pipeline YAML was missing the following tasks. Not sure why this isn't included in the ASP.NET Core template, very confusing for developers new to Azure DevOps.
- task: DotNetCoreCLI#2
inputs:
command: 'publish'
publishWebProjects: true
- task: CopyFiles#2
inputs:
targetFolder: '$(Build.ArtifactStagingDirectory)'
- task: PublishBuildArtifacts#1
inputs:
PathtoPublish: '$(Build.ArtifactStagingDirectory)'
ArtifactName: 'drop'
publishLocation: 'Container'
When adding an Artifact of Source type "Build", select "Default version" as "Latest from the build pipeline default branch with tags", as follows: