Tech Tips

During the Covid 19 lock down I have been doing plenty of Zwift‘ing. However, I have started having problems getting the Zwift Companion App working reliably, when it used to work. Basically, Zwift itself was fine, though very slow to save when exiting, but the companion app could not seem to detect that I was actively Zwift’ing, but it’s other functions were OK. After much fiddling I found the issue was the network connection from my PC up to Zwift and nothing to do with the phone app....

The Problem Whilst doing a migration from an on-premised TFS to Azure DevOps Services for a client I had a strange issue with SQLPackage.exe. I had previously completed the dry run of the migration without any issues and started the live migration with a fully defined process and timings for a each stage. When I came to export the detached Team Project Collection DB I ran the same command as I had for the dry run...

This is one of those blog posts I write to remind my future self how I fixed a problem. The Problem I have a release that installs VSTest and runs some integration tests that target .NET 4.6 x64. All these tests worked fine in Visual Studio. However, I got the following errors for all tests when they were run in a release 2020-04-23T09:30:38.7544708Z vstest.console.exe "C:agent\_workr1aPaymentServicesdroptestartifactsPaymentService.IntegrationTests.dll" 2020-04-23T09:30:38.7545688Z /Settings:"C:agent\_work\_tempuxykzf03ik2.tmp.runsettings" 2020-04-23T09:30:38.7545808Z /Logger:"trx" 2020-04-23T09:30:38.7545937Z /TestAdapterPath:"C:agent\_workr1aPaymentServicesdroptestartifacts" 2020-04-23T09:30:39....

In the past I have documented the build and release process I use for my Azure DevOps Pipeline Extensions and also detailed how I have started to move the build phases to YAML. Well now I consider that multistage YAML pipelines are mature enough to allow me to do my whole release pipeline in YAML, hence this post. My pipeline performs a number of stages, you can find a sample pipeline here....

I have recently hit a problem that some of my Azure DevOps YAML pipelines, that I use to build my Azure DevOps Pipeline Extensions, are not triggering on a new PR being created on GitHub. I did not get to the bottom of why this is happening, but I found a fix. Check and of make a note of any UI declared variables in your Azure DevOps YAML Pipeline that is not triggering Delete the pipeline Re-add the pipeline, linking to the YAML file hosted on GitHub....

Background GitHub is a great system for individuals and OSS communities for both public and private project. However, corporate customers commonly want more control over their system than the standard GitHub offering. It is for this reason GitHub offers GitHub Enterprise. For most corporates, the essential feature that GitHub Enterprise offers is the use Single Sign On (SSO) i.e. allowing users to login to GitHub using their corporate directory accounts....

Problem I recently tripped myself up whist adding SonarQube analysis to a rather complex Azure DevOps build. The build has two VsTest steps, both were using the same folder for their test result files. When the first VsTest task ran it created the expected .TRX and .COVERAGE files and then published its results to Azure DevOps, but when the second VsTest task ran it over wrote this folder, deleting the files already present, before it generated and published it results....

I wrote recently about Creating Hyper-V hosted Azure DevOps Private Agents based on the same VM images as used by Microsoft for their Hosted Agent. As discussed in that post, using this model you will recreate your build agent VMs on a regular basis, as opposed to patching them. When I came to do this recently I found that the Packer image generation was failing with errors related to accessing packages....

I have recently been doing a TFS 2015 to Azure DevOps Server 2019.1 upgrade for a client. The first for a while, I have been working with Azure DevOps Service mostly of late. Anyway I saw an issue I had never seen before with any version of TFS, and I could find no information on the Internet. The Problem The error occurred when I tried to queue a new build after the upgrade, the build instantly failed with the error...

Hit a strange problem today trying to do a simple Work Item update via the Azure DevOps REST API. To do a WI update you need to call the REST API Using the verb PATCH With the Header “Content-Type” set to “application/json-patch+json” Include in the Body the current WI update revision (to make sure you are updating the current version) So the first step is to get the current WI values to find the current revision....