Posts

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. ...

The Issue I recently upgraded a clients Azure DevOps server from 2019 to 2022. This required a new application tier VM due to the change in supported versions of Windows Server between the two versions. Unfortunately, the client’s developers had always accessed the old Azure DevOps Server using the VMs FQDN, as opposed to a DNS managed alias. Hence, given they wanted to minimise change, the plan was to create a DNS Alias so they could continue to use the same URLs and TFVC workspaces mappings. ...

The Issue Last week I noticed that the staging URL that is normally output as a comment was missing from new GitHub PRs. Previously, this URL was added automatically by the Azure/static-web-apps-deploy GitHub Action for PRs in our Hugo based websites. After a bit of digging, I noticed a warning message in the logs of the Action that said: … Done Zipping App Artifacts Uploading build artifacts. Finished Upload. Polling on deployment. Status: InProgress. Time: 0.178533(s) Status: Succeeded. Time: 15.3731517(s) Deployment Complete :) Visit your site at: https://white-glacier-0d2380f03-300.westeurope.2.azurestaticapps.net Unexectedly failed to add GitHub comment. Thanks for using Azure Static Web Apps! Exiting ...

Just a little reminder, probably to my future self, to not call your Azure DevOps YAML Deployment stage ‘deployment’. If you forget you can expect to waste plenty of time, like we did last week, with environment agents not picking up queued jobs with no diagnostic logging messages to give you a clue as to what is going on. This issue has been reported on StackOverflow where it was pointed out that the official documentation used ‘deployment’ as the stage name. The good news is that at least the documentation is now fixed, but there is still the chance you can make this naming mistake all on your own. ...