How to run your own maintenance job on Azure DevOps pipelines

author Richard Fennell calendar Jul 12, 2023 · 5 min read · DevOps  ·
Share on: linkedin copy

Updated: 19 Jul 2023 - Revised the post to use Az CLI Task as opposed to a PowerShell Task

Updated: 29 Aug 2024 - Revised the PowerShell as original version was not working. Also see follow up post on using Workload Identity federation

Background

Azure DevOps Pipelines have a built in mechanism to run maintenance jobs on a schedule. This is great for cleaning out old temporary data, but what if you want to run your own maintenance job?

Writing a pipeline to run on a schedule is not in itself difficult. The problem is how to schedule so it runs on all available agents in all available agent pools.

Implementation

There are a number of ways to tackle this, but the way I chose was to use two YAML pipelines and the Az DevOps CLI

The Maintenance Job Pipeline

The contents of the pipeline to run on each agent is down to your requirements. In my case I wanted to run a PowerShell script to update the cached vulnerability databases for the OWSAP Dependency checker.

The key point to note is that I expose a pair of parameters , aliased into variables, to target the pool and agent. This is so I can pass them in from the calling pipeline.

 1# This is the pipeline that runs any scheduled maintenance jobs
 2# we wish to run in addition to the built in Azure DevOps Maintenance jobs
 3
 4# The parameters to target each pool and agent
 5parameters:
 6  - name: pool
 7  - name: agent
 8
 9# We cannot use to the parameters directly else we get a 'A template expression is not allowed in this context'
10# However, if we alias them with a variable they work
11variables:
12  - name: pool
13    value: ${{parameters.pool}}
14  - name: agent
15    value: ${{parameters.agent}}
16 
17trigger: none
18
19pool:
20  name: "$(pool)"
21  demands: Agent.Name -equals $(agent)
22
23steps:
24- task: dependency-check-build-task@6
25  displayName: "Vunerability Scan Exploited Vulnerabilities update check"
26  inputs:
27    projectName: 'Maintainance'
28    scanPath: '.'
29    format: 'HTML'

The Scheduler Job Pipeline

Note: Previously I had run the script using an Azure DevOps PowerShell task, but this had the limitation I had to pass a personal PAT of a user with enough permissions to access the organisation level agent pools using the AZ CLI. This was done using an environment variable injected into the PowerShell.

1- task: PowerShell@2
2 inputs:
3   targetType: 'inline'
4   script: |
5     # all the script lines     
6  displayName: 'Trigger maintainance builds on all active agents'
7 env:
8   AZURE_DEVOPS_EXT_PAT: $(PAT)

I had hoped to use the $(System.AccessToken), but though this works for some az pipeline commands it returns an empty set when querying the agent pools. I had assumed it was a permissions issue, but couldn't find the solution. Hence the use of a PAT, until I swapped to this solution using the Az CLI task.

The maintenance pipeline, shown above, is called from a scheduled pipeline, shown below, that runs a script that calls the AZ CLI to find all the agents to target using the Azure CLI Task

 1# Scheduler Pipeline
 2variables:
 3  # filter to limit the scope of agent pools to consider
 4  - name: PoolNamePrefix
 5    value: "BM-"
 6  # the pipeline to run on each agent
 7  - name: BuildDefintion 
 8    value: "ScheduledMaintenanceBuild"
 9
10trigger: none
11
12schedules:
13- cron: '0 0 * * *'
14  displayName: Daily midnight build
15  branches:
16    include:
17    - main
18
19pool:
20  name: MyAgentPool
21
22steps:
23- task: AzureCLI@2
24  inputs:
25    # The Azure Subscription is the link to a Service Principle
26    # with permission to access the agent pools and queue builds
27    azureSubscription: 'AzureDevOpsAgentAutomation'
28    scriptType: 'pscore'
29    scriptLocation: 'inlineScript'
30    inlineScript: |
31      write-host "Find the agent pools with the prefix '$(PoolNamePrefix)'"
32      $Pools = $(az pipelines pool list --organization $(System.TeamFoundationCollectionUri) --query "[? (starts_with(name,'$(PoolNamePrefix)'))].[id,name]" --output tsv)
33
34      write-host "$($Pools.count) found"
35      foreach ($pool in $pools) {
36          # ugly but works with tsv format data
37          $poolSplit = $pool.Split("`t")
38          $poolID = $poolSplit[0]
39          $poolName = $poolSplit[1]
40          
41          write-host "Find the agents the pool '$poolName'"
42
43          $Agents = az pipelines agent list --organization $(System.TeamFoundationCollectionUri) --pool-id $PoolID --query "[?enabled].name"  --output tsv 
44
45          foreach ($Agent in $Agents) {
46              $buildNameid = $(az pipelines run --organization $(System.TeamFoundationCollectionUri) --name $(BuildDefintion) --project $(System.TeamProject) --parameters "pool=$PoolName" "agent=$Agent" "nvdapikey=$(nvdapikey)" --query "name"  --output tsv )
47              Write-host "Queued build $buildNameid on $agent"
48          }
49      }      
50  displayName: 'Trigger maintainance builds on all active agents'

Note: A change required if running this script in the AZ CLI task, as opposed to the PowerShell task, is that you need to specify the --organization parameter. It is not picked up automatically. If this is not done you get the somewhat confusing error

ERROR: TF401019: The Git repository with name or identifier <name of the Git repo> does not exist or you do not have permissions for the operation you are attempting. Operation returned a 404 status code.

For this pipeline to run you need to setup a Service Principle and Service Connection for the Az CLI task to use. This is done as follows

  1. Create a Service Principle in Azure AD and add it to the Azure DevOps organisation as an Azure DevOps Service connection

Note: I used the az ad sp create-for-rbac command to create the service principle, but when I tried to add it as a service connection I got a 404 error about lack of permissions in the subscription. It seems the issue was the new service principle must be granted at least read permissions in the subscription being used to register it in Azure DevOps. This is not done by default

  1. Add the new service principle as a user to the Azure DevOps organisation
  2. Grant the new service principle reader permissions at the organisation Agent Pool level
  3. In the Team Project that contains your maintenance pipelines, in the Pipelines > manage permissions, grant the new service principle the queue builds permissions

Summary

This is a simple way to run your own maintenance jobs on all agents in all pools. It is not the only way, but it is one that works for my current needs.