Introduction Last year I posted on how to create your own Azure DevOps maintenance jobs. This solution has been working well for me, until the Azure DevOps Service connection’s Entra ID Service Principle secret expired. So, I thought it well worth revisiting the creation of this maintenance job but this time using Workload Identity federation to authenticate, and hence never again have to worry about the secret expiring. Updated Setup Process Note: This is a modification to the creation of the service connection, but the core the maintenance job setup remains the same as in my original post ...

The Issue Whilst refreshing an end-to-end devops demo, one I use for both Azure DevOps and GitHub, I hit a problem. The new Playwright UX Tests, that were replacing old Selenium ones, were failing on the GitHub hosted runner. The strange thing was the same tests worked perfectly on: My local development machine The Azure DevOps hosted runner And strangest of all, a GitHub self hosted runner The Solution Adding some logging to the tests showed the actual issue was that on the GitHub hosted runner the code to count the rows in an HTML table was always returning 0. ...

The Issue I have been recently refreshing a GitHub end-to-end demo I use for talks and workshops that I had not looked at for a while. It shows how legacy code bases can be deployed with GitHub Actions and Azure App Services. The demo uses MSDeploy to deploy a ASP.NET web application to Azure App Services. The MSDeploy package is created as part of the GitHub Action workflow. The workflow uses a PowerShell script to do the deployment using the following: ...

Background Our on premise build agents, though using the same image as the Microsoft hosted agents (generated using Packer, as I have previously posted about), have some extra setup done by Lability as they are deployed to a Hyper-V host. Most of this is specific to the needs of running on Hyper-V e.g. setting up networking, creating a 2nd disk to act as a working store for the build agent, and of course installing the Azure DevOps agent itself. ...

Background We have for many years based our Azure DevOps build and release pipelines on on-premise agents. This was done to provide a means to scale up each agent using ‘bigger & faster’ local VMs then the Microsoft Hosted agents provided, and to utilise spare Hyper-V hosts we had after moving services such as SharePoint to Office 365. To provide consistency of build agent experience to our developers, we decided we wished to use the same VM images on our on-premise agents as used by the Microsoft’s hosted agent pools. I have blogged previously on the process of creating these images with Packer and deploying them to Hyper-V with Lability. This is a process we still follow every couple of months to keep the images reasonably up to date. ...

Azure DevOps Server 2022.2 has recently been released. Unexpectedly this minor 2022.2 release includes a change in supported versions of SQL, SQL2017 support has been dropped. So, if someone attempted an upgrade from 2022.1 to 2022.2 they will get the error “TF255146: The SQL Server instance you specified (nnnnn) is version ‘SQL Server 2017 RTM’, which is not supported by this version of Azure DevOps Server. For more information about supported versions of SQL Server, visit https://www.visualstudio.com/docs/setup-admin/requirements " ...

The Issue Yesterday I posted about converting ARM output variables to Azure DevOps pipeline variables Whilst using the pattern I discussed we hit an interesting problem. On my test pipeline I had the following YAML and it was working as expected. - task: PowerShell@2 displayName: Obtain Azure Deployment outputs inputs: targetType: 'inline' script: | if (![string]::IsNullOrEmpty( $env:deploymentOutputs )) { $DeploymentOutputs = convertfrom-json $env:deploymentOutputs $DeploymentOutputs.PSObject.Properties | ForEach-Object { $keyname = $_.Name $value = $_.Value.value Write-Host "The value of [$keyName] is [$value]" Write-Host "##vso[task.setvariable variable=$keyname]$value" } } However, on the first production project I tried this on, the script ran but did not create the expected variables. The issue was that the variable $env:deploymentOutputs was empty, even though the ARM deployment had completed successfully and the outputs were available in the pipeline debug logs. ...

The Issue Historically, we have used Kees Schollaart’s ARM Outputs Azure DevOps task to convert the output from an ARM template deployment into a variable that can be used in a subsequent Azure DevOps pipeline task, using the general form - task: AzureResourceManagerTemplateDeployment@3 displayName: Deploy the main template inputs: deploymentScope: 'Resource Group' azureResourceManagerConnection: 'ARMConnEndpoint' subscriptionId: '$(SubscriptionId)' action: 'Create Or Update Resource Group' resourceGroupName: '$(ResourceGroup)' location: '$(AzureRegion)' templateLocation: 'Linked artifact' csmFile: '$(Pipeline.Workspace)/ARMtemplates/azuredeploy.json' overrideParameters: >- -staticSitelocation "westeurope" -projectName "$(projectName)" -env "$(environment)" deploymentMode: 'Incremental' - task: ARM Outputs@6 displayName: Obtain outputs from the deployment of the Main Deploy name: 'MainDeployOutput' inputs: ConnectedServiceNameSelector: 'ConnectedServiceNameARM' ConnectedServiceNameARM: 'ARMConnEndpoint' resourceGroupName: '$(ResourceGroup)' whenLastDeploymentIsFailed: 'fail' This process has been working well until we upgraded our service connections to workload identity federation. As soon as we did this the ARM Outputs@6 task started failing with the error message ...

Introduction I have previously blogged a good deal on Azure DevOps variable evaluation, see here and here, but the saga continues… When variables exist Today I realised, something I guess should have been obvious, that when you manually queue a run, pre-defined variables such as $(Build.SourceBranchName) are not available until the pipeline is compiled and starts running. This is because though there is a value in UI branch combo but this value is not in $(Build.SourceBranchName) until the pipeline starts running. ...

The Issue Whilst working on an Azure DevOps YAML pipeline for a solution that used Git Submodules we hit a problem with the checkout of the repo and submodule using the YAML jobs: - job: 'Build' steps: - checkout: self submodules: true It got the main Git repo, but failed with the following error git submodule sync git --config-env=http.https://myorg@dev.azure.com.extraheader=env_var_http.https://myorg@dev.azure.com.extraheader submodule update --init --force Submodule 'Library' (https://myorg@dev.azure.com/myorg/myproject/_git/Library) registered for path 'Library' Cloning into 'D:/a/1/s/Library'... remote: TF401019: The Git repository with name or identifier Library does not exist or you do not have permissions for the operation you are attempting. The Analysis The issue is that the build agent access token was scoped to only the repo containing the YAML pipeline and not the submodule repo, even though they are in the same Azure DevOps Team Project. ...