Background I’ve written a good few extensions for Azure DevOps Services. Most of the early ones I wrote were written in PowerShell, but of late I have tended to use Typescript (targeting Node.JS) for the added cross-platform support. This has led me to consider if it was worth the effort to convert all my legacy extensions to support cross-platform usage? This is of course assuming the tasks the extension contains are useful on a non-Window platform....

Introduction There are times when you need to run Private Azure DevOps agents as opposed to using one of the hosted ones provided by Microsoft. This could be for a variety of reasons, including needing to access resources inside your corporate network or needing to have a special hardware specification or set of software installed on the agent. If using such private agents, you really need to have an easy way to provision them....

Issue I have been busy automating the provision of our private Azure DevOps Agents using Packer and Lability; a more details blog post is on the way. All has been going OK on my test rig, but when came to run the automation pipeline on our main build HyperV host I got an error > Get-VmcConfigurationData : Datafile EnvironmentsBuildAgent-VS2017BuildAgent-VS2017.psd1 NOT FOUND. Exiting But the file was there! I check the default Lability paths, but all these looked OK, and none pointed to my environment location on C: anyway...

Over the past few days I have published two major enhancements to my Azure DevOps Cross Platform Release Notes Extension. Added Support for Builds Prior to version 2.17.x this extension could only be used in Releases. This was because it used Release specific calls provided in the Microsoft API to work out the work items and changesets/commits associated with the Release. This is unlike my older PowerShell based Release Notes Extension which was initially developed for Builds and only later enhanced to work in Releases, but achieved this using my own logic to iterate across Builds associated with Releases to work out the associations....

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