Recently I migrated from the traditional Graphic deployment pipelines to the reusable yaml build and deployment pipelines.
The yaml build pipelines are delivering (multiple) artifacts which are used in a deployment pipeline.
When running the deployment pipeline (making use of parameters and settings), yaml templates, etc...
I see, when the pipeline is finished, a description like:
<build id> - <latest check-in message where the deployment pipeline
is located>
Since the deployment pipeline is not located in the same repo as the build pipelines, the message/description does not relate to the actual state.
Is it possible to change these messages/descriptions so when I display the runs of the pipeline I can see what is important for me, instead of the last check-in message?
Thanks, Bart
This pipeline setting will stop it adding the commit description when it prints the pipeline run name:
appendCommitMessageToRunName: false
Ref: https://learn.microsoft.com/en-us/azure/devops/pipelines/yaml-schema/pipeline?view=azure-pipelines#pipeline-stages
Note: this is a new feature as of September 2022; previously, the commit message was always shown.
Related
We are currently switching over from Classic (UI) Azure Pipelines to YAML pipelines.
We would like to deploy a branch every night to an environment (when changes have occurred) and also be able to deploy to this environment manually. With the Classic pipelines it was easy to setup a scheduled deploy to an environment that could also be triggered manually when desired.
In the new YAML pipelines we currently use the "Business hours"
check to make sure the nightly deploy takes place, but we are unable to override the check when a manual deployment is needed.
Is there a way to setup a YAML pipeline where a deploy waits for either a manual approval or a scheduled trigger to occur?
Like many before me I'm struggling hard with configuring pipeline triggers in Azure DevOps.
Background:
single project in the Organization
three branches: main, Infrastructure, Application
The branches are kind of independent of each other. They are never merged into main either.
I have a pipeline which deploys two App Services. The YAML file for this pipeline is in the Infrastructure branch. The Default branch for manual and scheduled builds is set to Infrastructure.
Then I have 2 pipelines, each to deploy a different App to the App Service. The YAMLs for those pipelines are in the Application branch. The Default branch for manual and scheduled builds is set to Application.
By themselves, the pipelines work perfectly fine. However what I am trying to achieve is to trigger the App pipelines after the App Service pipeline finishes. And no matter what combination of settings I try, I can't get it to work.
This is currently how it looks like in the n-th version of the YAML:
name: 'deploy-webapp-002'
pool:
vmImage: windows-latest
resources:
pipelines:
- pipeline: 'Deploy App Services' # Internal name of the source pipeline, used elsewhere within this YAML
# e.g. to reference published artifacts
source: deploy-appservices # Azure Pipelines name of the source pipeline referenced
project: HomeLab # Required only if the source pipeline is in another project
trigger:
branches:
include:
- Infrastructure
- Application
pr: none
trigger: none
Is it even possible to do what I'm trying to do?
If yes, what settings should be specified in the Resources/Pipelines section in the YAML, and how should the Default branch for manual and scheduled builds look like for each of those pipelines?
I can reproduce the same issue when I put the YAML files separately in two branches and set the default branch.
Refer to this doc: Define a pipelines resource
When you define a resource trigger, if its pipeline resource is from the same repository (say self) as the current pipeline, triggering follows the same branch and commit on which the event is raised. But, if the pipeline resource is from a different repository, the current pipeline triggers on the default branch of the self repository.
In your caseļ¼ you are using the same repo. So triggering follows the same branch and commit on which the event is raised.
To solve this issue, you need to copy the YAML file in Application Branch to Infrastructure Branch.
On the other hand, you can also try to set Build completion trigger manually on UI.
For example:
I have a multi-stage YAML pipeline using which I run my automated tests against different environments(Dev, Test, Pre-prod, etc). I wanted to run these automated tests directly from the test plan by configuring the build and release pipeline using Azure test plan settings.
But I couldn't see my release stages after selecting the build in the build pipeline dropdown. It is working fine for my classic UI release pipeline, not for the YAML muti-stage.
Does YAML multi-stage support this functionality?
This seems to rely on the "old releases". But the steps and code it generates could easily be ported over to the new YAML pipelines. But you'd have to do it by hand.
You could create a temporary "old style" pipeline, configure it to see what all gets generated and then duplicate those tasks to your YAML pipeline.
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:
We have been converting our Release pipelines in Azure DevOps to instead be YAML files that run as Pipelines. This is so we can store our deployment process as code. The deployment process is working well - so a developer commits code and the Pipeline builds and publishes the artifact in one stage and then it auto-deploys to the QA environment in another stage. Subsequent stages deploy to an Environment (e.g. QA, Staging, Production) each of which requires some approval(s). The deployments themselves aren't the issue.
What I'm struggling with is unlike the old Releases there isn't a dashboard that will tell me which version of the project is in each environment. The Pipeline summary represents each stage for the Run as a dot (running, succeeded, failed, canceled, etc.) but wasn't built to represent what each environment has (probably because a stage doesn't have to be a deployment).
Is there somewhere else I can look for this information or do I have to build my own dashboard by calling the AzDO APIs? Looking at the Environment gives a list and I can root through the history, but that's not the experience our developers are looking for.