I have separate yaml pipelines for CI and CD in Azure DevOps Services.
CI pipeline will publish an artifact to a file share location. \fileshare\project
And in the CD pipeline I am using the CI pipeline as resource so that I can deploy the artifact produced from the CI pipeline.
resources:
pipelines:
- pipeline: POC_pipeline # identifier for the pipeline resource
source: CI-pipeline_YAML # source pipeline definition name
My question is how can I download this artifact and what's the pre-defined variable name to get the path of the published artifact from CI-pipeline.
I tried using but it doesn't download anything, this only works when I push the artifact to Azure DevOps.
steps:
- download: POC_pipeline
It seems download task cannot download artifacts that published to a file share. I can reproduce the same issue. You can report this problem(Click Report a problem and choose Azure devops) to Microsoft development team.
As workaround, you can use Download Fileshare Artifacts task to download fileshare artifacts.
- task: DownloadFileshareArtifacts#1
inputs:
filesharePath: '\fileshare\project'
artifactName: artifactName
downloadPath: $(Build.ArtifactStagingDirectory)
The artifacts will be downloaded to folder specified in downloadPath. In above example you will find the artifacts in $(Build.ArtifactStagingDirectory)/artifactName (ie. C:\agent\_work\2\a\artifactName)
Check here to find more predefined variables.
You can also use Download Pipeline Artifacts task to download the fileshare artifacts. You need to specify the source as specific, and other project, pipeline,runVersion attributes. See below:
- task: DownloadPipelineArtifact#2
inputs:
source: specific
project: yourProjectName
pipeline: CI-pipeline_YAML
runVersion: latest
path: $(Build.ArtifactStagingDirectory)
The artifacts will be downloaded to folder specified in path.
Noted: you need to run your pipeline on self-hosted agents which can access the file share.(It will fail with error `Unable to read directory \fileshare\project" on cloud agents).
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:
Is there any possibility to get the URL of a published artifact in the yml pipeline, so it can be used in further pipeline tasks/steps?
Sadly, the Microsoft Docs on the two tasks don't give any hints if the published path value is available in any way.
- task: PublishBuildArtifacts#1
inputs:
pathToPublish: report.html
artifactName: HtmlReport
It depends on where you're using the artifacts - Deployment jobs will typically automatically download the artifacts into the $(Pipeline.Workspace) folder with the same name as you declare in the build task.
So in your case it would be located at $(Pipeline.Workspace)\HtmlReport
You can also use the Download Build Artifacts task to download a specific artifact:
- task: DownloadBuildArtifacts#0
inputs:
buildType: 'current'
downloadType: 'single'
artifactName: 'HtmlReport`
This is useful if you have multiple published artifacts and you only want to download one of them in a later stage. There are other options if you wish to download an artifact from a different pipeline.
Note that the Publish Build Artifacts task is now deprecated and you are recommended to use the newer Publish Pipeline Artifacts and matching Download Pipeline Artifacts tasks:
We recommend upgrading from build artifacts (PublishBuildArtifacts#1 and DownloadBuildArtifacts#0) to pipeline artifacts (PublishPipelineArtifact#1 and DownloadPipelineArtifact#2) for faster performance.
To achieve continuous deployment, we used a (classic) release pipeline on Azure DevOps to deploy a webservice to a VM in our intranet. To benefit of a yaml deployment pipeline, I replaced our former deployment pool agent on that VM with an environment agent.
For the actual deployment, we use the IIS Web App Deploy task. The source directory for this tasks defaults to $(System.DefaultWorkingDirectory)\**\*.zip. The $(System.DefaultWorkingDirectory) translates to the a subdirectory of the concrete release.
Unfortunately for me, the environment agent downloads the artifact next to the a-folder instead of into it like the environment pool agent. Thus the default settings of the deploy task cannot find it. I am aware that I can easily work around this issue by using $(System.DefaultWorkingDirectory)\..\**\*.zip. I was just wondering why Microsoft introduced such a development speed bump into the environment agents.
Is there any way I can make the environment agent download the artifact into $(System.DefaultWorkingDirectory) aka. a instead of next to it?
If you are using deployment job in yaml pipeline. The artifacts will be automatically downloaded to $(Pipeline.Workspace)/(folder next to $(System.DefaultWorkingDirectory)) in deployment jobs. See below extract from here:
Artifacts from the current pipeline are downloaded to $(Pipeline.Workspace)/.
Artifacts from the associated pipeline resource are downloaded to $(Pipeline.Workspace)/{pipeline resource identifier}/.
All available artifacts from the current pipeline and from the associated pipeline resources are automatically downloaded in deployment jobs and made available for your deployment. To prevent downloads, specify download: none.
To make the environment agent download the artifact into $(System.DefaultWorkingDirectory).
You can specify download: none. And use Download Pipeline Artifacts task and specify the path parameter to download your artifacts to $(System.DefaultWorkingDirectory). See below:
- deployment:
environment: Dev
strategy:
runOnce:
deploy:
steps:
- download: none #prevent automatically download
- task: DownloadPipelineArtifact#2
inputs:
buildType: 'current'
targetPath: '$(System.DefaultWorkingDirectory)' # download to default folder.
Anther workaround is to change the source directory for IIS Web App Deploy task defaults to $(Pipeline.Workspace)\**\*.zip
When changing from Classic to YAML pipelines for deployments, you will probably need to change $(System.DefaultWorkingDirectory) to $(Pipeline.Workspace). You can verify this with the steps:
- pwsh: Get-ChildItem $(System.DefaultWorkingDirectory) -Recurse
displayName: Check System.DefaultWorkingDirectory
- pwsh: Get-ChildItem $(Pipeline.Workspace) -Recurse
displayName: Check Pipeline.Workspace
(Yes, this is an awfully verbose way of doing it. It will, though, give you more complete insight into the file structure supporting your job.)
I have a repo in Azure devops which is using 'ant all' command to build an ear file. This ear file contain should a war file built from another repo in the azure.
How can I include this war file in the build?
Thanks.
If your war file is built from code hosted in another repo and not is a part of the repo itself. You can publish pipeline artifact and download it in your next pipeline. Here you have doc article about this. And here description of the task itself.
In short to publish you should add code like this:
steps:
- publish: $(System.DefaultWorkingDirectory)/bin/WebApp
artifact: WebApp
and to download:
# Download artifacts from a specific pipeline.
- task: DownloadPipelineArtifact#2
inputs:
source: 'specific'
project: 'FabrikamFiber'
pipeline: 12
runVersion: 'latest'
If you mean the war file is already in another repo in the same organization, you could check multiple checkout, by using multiple checkout steps in your pipeline, you can fetch and check out other repositories in addition to the one you use to store your YAML pipeline.
steps:
- checkout: git://MyProject/MyRepo # Azure Repos Git repository in the same organization
- checkout: self
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: