In Azure DevOps classic pipelines you can have a build pipeline for creating the artifact and a release pipeline for deploying it. This means that whatever stored prexisting artifact could be deployed simply launching the release pipeline and selecting the artifact´s version (typical usage: rolling back the current deployed artifact to a previous version)
How this can be achieved in Multi-Stage pipeline? Any way of launching only the deployment stage selecting the artifact to be deployed?
Regards
How this can be achieved in Multi-Stage pipeline? Any way of launching only the deployment stage selecting the artifact to be deployed?
Indeed, this is very convenient to choose prexisting artifact based on actual demands, but what you want does not supported in Multi-Stage pipeline until now.
This request already reported to the MS product team:
Select artifacts in YAML release pipeline
This feature have been added in the last sprint:
Pipeline resource version picker in the create run dialogue
However, as I test, it seems this feature has not been deployed in all regions:
If it not deployed in your region, you could try to use the task Download Pipeline Artifacts task with the runId input:
- task: DownloadPipelineArtifact#2
inputs:
source: 'specific'
artifact: 'drop'
path: $(Build.SourcesDirectory)/bin
project: 'AndroidBuild'
pipeline: 12
runVersion: 'specific'
runId: $(buildid)
Then use pass queue variable buildid when we queue the build:
Hope this helps.
This can be done by having two pipelines. one pipeline for your build where your pipeline produces an artifact and create another pipeline for your release stages. In the release pipeline, you can set the resources to point to another build or pipeline. where you can consume your previously produced artifact(including older build version) to deployment stages.
See:
YAML Resources
Your release YAML pipeline can specify what resources it needs. You can specify an existing build or another pipeline.
resources:
pipelines:
- pipeline: SmartHotel-resource # identifier for the resource (used in pipeline resource variables)
source: SmartHotel-CI # name of the pipeline that produces an artifact
However, Keeping them separate just leads to move overhead and maintenance.
Related
I'm building a multi-stage pipeline in which my build stage stores a single file as a pipeline artifact. In the deployment stage the artifact is automatically download and I need the name of the file in order to proceed with the following steps.
Currently, I'm publishing as a variable the name of the file stored as the artifact of the build. I'm wondering if the download task would be able to provide the name of the file so that I can further decouple the build and deploy stages.
This is what I'm using right now:
- bash: |
jarFile=`ls -1 *.jar`
echo "##vso[task.setvariable variable=jarFile;isOutput=true]${jarFile}"
workingDirectory: target
name: mavenTarget
displayName: Finds name of built `.jar` file
And then in the deployment stage:
variables:
- name: jarFile
value: $[ stageDependencies.ci.build.outputs['mavenTarget.jarFile'] ]
I'm wondering if the download task would be able to provide the name of the file so that I can further decouple the build and deploy stages.
I am afraid that the Download build artifacts task has no built-in output variable that can represent the name of an artifact or the files in the Artifact.
The output variable of the download artifacts task is XXX.buildnumber. It doesn't contain the info about Artifacts Name or the files in Artifacts.
The cross-stage variables used in your Current YAML is an efficient way. You can continue to use the method.
First - I know that according to the official MS documentation the built in functionality for updating work items with release status via the deployment control is only supported in the release pipelines and not the multi stage YAML pipelines (see first note documented here: https://learn.microsoft.com/en-us/azure/devops/boards/work-items/work-item-deployments-control?view=azure-devops)
Has anyone used powershell or the Azure DevOps rest api's to create an addon or integration that can update the work item with the correct information to automate the linkage of work items to the release environment information given that this functionality doesn't appear to be available for the yaml release pipelines?
Yes. The Deployment field is not supported by Yaml Pipeline. This feature is only for Release Pipeline.
If you want to link Yaml Pipeline to Work item, it can be linked as Build type.
To achieve this in YAML pipeline, you can try to use the Task: WorkItem Updater task
from WorkItem Updater
- task: WorkItemUpdater#2
displayName: 'WorkItem Updater'
inputs:
workItemType: xx
workitemLimit: xx
linkBuild: true
Result:
I have an Azure DevOps pipeline that first builds a Function App and then deploys it through several different stages. My goal is not have the deployment stages trigger automatically.
When using releases, I'm able to achieve my goal by defining pre-deployment checks so that deployment to a stage is not triggered automatically. Since there is no option to make deployment of a stage 'manual after stage', I have to add an artefact filter to the relevant stage and set it to exclude *.
Unfortunately, stage triggers and artefact filters don't appear to exist for pipelines -
YAML schema reference
The environments that I can link to deployment stages do include approvals and checks, but these appear to be very limited and of no real use.
Define approvals and checks
Currently, manual approval and evaluate artifact are the only available checks
I have attempted to add a manual intervention, but despite the task being available through the pipeline assistant it does not work on a pipeline, only on a release.
Manual Intervention task
This task is supported only in classic release pipelines.
How can I achieve my goal of manual deployment to stages of a pipeline?
Here is an example of my pipeline.
stages:
- stage: Publish
displayName: Publish Function App
jobs:
- ...
- stage: Dev
displayName: Deploy Dev
jobs:
- ...
- stage: Staging
displayName: Deploy Staging
jobs:
- ...
- stage: Production
displayName: Deploy Production
jobs:
- ...
How can I achieve my goal of manual deployment to stages of a
pipeline?
Sorry but as I know manual trigger for yaml pipeline is not available currently. This feature request has been submitted to our User Voice forum. You can vote it and track the issue there, so that you'll get notifications if there's any update.
According to your scenario, have you tried the approvals? If we set the approvals in Environments, the deployment job would stop and wait for manual approvals. The deployment to a stage won't really start until we manually approve that, I think it's also helpful for your scenario. Here's one blog which you can refer to.
I created an azure build pipe line and published the artifacts. While releasing I want to know the artifact is created or not. How to check the availability of Published Pipeline Artifacts in azure pipeline release
How to check availability of Published Pipeline Artifacts in azure pipeline release
Since you have published the artifacts, you do not need to check the availability of Published Pipeline Artifacts in azure pipeline release on purpose.
That because the built-in Download Artifacts will check and download the Pipeline Artifacts in azure pipeline when your release source type is Build:
Besides, if you want to manually check the the availability of Published Pipeline Artifacts in azure pipeline release, you could use the Download Build Artifacts task to download the artifact to check it.
Hope this helps.
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: