Posted on Leave a comment

Change name for Azure devops pipeline

A common requirement when you work on your pipelines would be to name them according to your needs.

By default Azure devops name your pipeline with the buildID and the commit that initiated the build as shown below.

In order to change the name of the pipeline you can use the name keyword.

name: mypipeline

trigger:
- none

pool:
  vmImage: ubuntu-latest

steps:
- script: echo Hello, world!
  displayName: 'Run a one-line script'

Then you will have your custom name in the run of the pipeline.

Also from September 2022 and later, you can also remove the commit message from the title using appendCommitMessageToRunName

So by also adding this option

name: mypipeline
appendCommitMessageToRunName: false

trigger:
- none

pool:
  vmImage: ubuntu-latest

steps:
- script: echo Hello, world!
  displayName: 'Run a one-line script'

I will get only my preferred name on the pipeline run.

YouTube tutorial:

Posted on Leave a comment

Success pipeline state on GitHub with pipeline failure

When your pipeline fails on Azure DevOps and the source code is gathered from GitHub (using a service connection) you will notice a failure icon on the repository because the status of the run from Azure DevOps is reported to GitHub. This is the normal behavior and we want it to work like that.

Lets take as example the below run.

The failure will be visible on the github along with the particular commit.

However sometimes we need to allow tasks fail without reporting a failure state on GitHub. You can do that by using continueOnError keyword. With this functionality you instruct the DevOps platform to allow failure for a particular task or job without stopping the pipeline.

trigger:
- none

pool:
  vmImage: ubuntu-latest

jobs:
- job: job1

  steps:
  - script: this script will fail
    continueOnError: true
    displayName:  task 1

  - task: PowerShell@2
    displayName: task 2
    inputs:
      targetType: 'inline'
      script: |
        Write-Host "Hello World"

This will result on a warning state for your pipeline on Azure DevOps.

This means that the pipeline has been executed successfully but some steps have failed.

Nevertheless the state on GitHub will be success as the pipeline is not in a failed state on Azure DevOps.

Posted on Leave a comment

Starting template for Azure devops pipeline

The below code can be used as a starter entry point for your DevOps pipelines. It is designed with best practices in mind with stages and jobs in order to isolate different functionalities and make it modular. You can include more stages,jobs,tasks by copy and pasting the code.

trigger:
- none

pool:
  vmImage: ubuntu-latest

stages:
- stage: stage1
  displayName: display name for your stage
  jobs:
  - job: job1
    displayName: display name for job1
    steps:
    - script: echo job1.task1
      displayName: running job1.task1

  - job: job2
    displayName: display name for job2
    steps:
    - script: echo job2.task1
      displayName: running job2.task1

The result is shown below

Posted on 1 Comment

Create approvals on build and release Azure DevOps pipelines

On Azure devops you have the option to create both build and release pipelines. The build pipelines can be created using entirely the .yml notation in comparison with the release pipelines which should be created using a GUI. Build and release pipelines have their differences when it comes to approvals.

For release pipelines in order to create an approval flow you need to navigate in the stage and click the thunder strike. There you can locate the pre-deployment approvals and also gates that can be configured for that stage.

You can also define post-deployment approvals by clicking the person icon on the stage.

On the other hand in order to create approvals on build pipelines you will need to first create an environment. From environments you need to create a new blank environment

Then you need to navigate inside the environment and select approvals and checks

The last step would be to create a deployment job through YAML and point that environment. Every job which is created as deployment and has the environment configured will go through the approvals configured.

Lets see for example the below pipeline:

trigger: none

pool:
  vmImage: ubuntu-latest


stages:

- stage: stage1
  
  displayName: stage1
  jobs:
  - deployment: job1
    displayName: job1
    environment: appservice-west
    strategy:
      runOnce:
        deploy:
          steps:
          - task: PowerShell@2
            displayName: run powershell 1
            inputs:
              targetType: 'inline'
              script: |
                Write-Host "Hello from powershell 1"

- stage: stage2
  dependsOn: stage1
  displayName: stage2
  jobs:
  - deployment: job2
    displayName: job2
    environment: appservice-west
    strategy:
      runOnce:
        deploy:
          steps:
          - task: PowerShell@2
            displayName: run powershell 2
            inputs:
              targetType: 'inline'
              script: |
                Write-Host "Hello from powershell 2"

Before the execution of job1 and job2 an approval will be asked the way it is configured from the environment.