Posts

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

Background I just upgraded our Azure/Docker container hosted SonarQube instance from 10.5.1 to 10.6.0. This was partly due to our usual upgrade process, we try to upgrade within a week or so of a new release, but also to address a specific Java issue we started to see when using the SonarQube@6 Azure DevOps tasks. The error was the SonarQube analysis completed successfully, but the clean up process failed with this JVM error. ...

The Problem I have an Azure DevOps YAML template that does some deployment actions using PowerShell. This template is used multiple locations. The problem is that the PowerShell step within the template needs a variable number of environment variables, set from values stored in an Azure DevOps variable Group. The number of variables is not fixed because they depend on the underlying commands the PowerShell script is triggering to do the deployment. ...

I have blogged in the past about Caching NVD Vulnerability Dependency data on hosted Azure DevOps Pipeline agents. Using the cache is a great way to speed up slow builds. However, today I was surprised to find I was getting cache misses on my pipeline, even though I was sure the cache should have been hit. There are rules over how the cache is used: The cache is specific to a pipeline definition, so there is no sharing of the cache between pipeline definitions The cache is only created if the pipeline is successful (running the post run tasks) The cache only lasts 7 days but what I had not realised was the cache is also specific to the branch in a not so obvious way. My pipeline was triggered off a PR, so the cache was being created on the ‘branch’ PR #123. This was working as expected, all runs of the PR triggered build used the cache after the initial run. However, if I manually triggered pipeline run of the same branch as the PR was using, there was a cache miss. ...

There is still time to register for the free Global DevOps Experience which is being run on the 15th of June at many venues around the world, including Black Marble’s offices. The Global DevOps Experience is a day full of learning and fun, as we immerse you in the world of DevOps and AI. You will learn about the latest trends and technologies, and work in a team to solve challenging exercises based around a realistic business scenario. ...