Issue I had an Azure DevOps YAML based pipeline that had been working but was now getting stuck with the message “Job is pending…” when trying to start a stage in which there is a deployment to an environment. Looking at the logs and Azure DevOps UI it was not obvious what the issue was. Solution Turns out it was due to environment checks and approvals. There was a branch policy on the environment....
I have blogged in the past ( here and here) about the complexities and possible areas of confusion with different types of Azure DevOps pipeline variables. I have also seen issues raised over how to access custom variables across jobs and stages. Safe to say, this is an area where it is really easy to get it wrong and end up with a null value. I have recently come across another edge case to add to the list of gotchas....
I have been doing some work with Azure DevOps multi-stage YAML pipelines using stage dependency variables and conditions. They can get confusing quickly, you need one syntax in one place and another elsewhere. So, here are a few things I have learnt… What are stage dependency variables? Stage Dependencies are the way you define which stage follows another in a multi-stage YAML pipeline. This is as opposed to just relying on the order they appear in the YAML file, the default order....
As I am sure you are all aware the preview of Visual Studio 2022 has just dropped, so it is time for me to update my Parameter.xml Generator Tool to support this new version of Visual Studio. But what does my extension do? As the Marketplace description says… A tool to generate parameters.xml files for MSdeploy from the existing web.config file or from an app.config file for use with your own bespoke configuration transformation system....
Introduction The use of variables is important in Azure DevOps pipelines, especially when using YML templates. They allow a single pipeline to be used for multiple branches/configurations etc. The most common form of variables you see is are the predefined built in variables e.g. $(Build.BuildNumber) and your own custom ones e.g. $(var). Usually the value of these variables are set before/as the build is run, as an input condition. But this is not the only way variables can be used....
Disks filling up on our private Azure DevOps agents is a constant battle. We have maintenance jobs setup on the agent pools, to clean out old build working folders nightly, but these don’t run often enough. We need a clean out more than once a day due to the number and size of our builds. To address this, with UI based builds, we successfully used the Post Build Cleanup Extension. However since we have moved many of our builds to YAML we found it not working so well....
I have just released Version 3.1.7 of my Azure DevOps Pipeline XplatGenerateReleaseNotes Extension. This new version allows you to build release notes within a Multi-Stage YAML build since the last successful release to the current (or named) stage in the pipeline as opposed to just last fully successful build. This gives more feature parity with the older UI based Releases functionality. To enable this new feature you need to set the checkStage: true flag and potentially the overrideStageName: AnotherStage if you wish the comparison to compare against a stage other than the current one....
Updated 30/Sep/21 to reflect changes in the Aggregator CLI setup process Updated 27/Mar/22 to fix broken links Background Back in the day I wrote a tool, TFS Alerts DSL, to do Work Item roll-up for TFS. Overtime I updated this to support VSTS (as Azure DevOps was then called), it’s final version is still available in the Azure DevOps Marketplace as the Azure DevOps Service Hooks DSL. So when I recently had a need for Work Item roll-up I did consider using my own tool, just for a short while....
The testing cycle for Release Notes Templates can be slow, requiring a build and release cycle. To try to speed this process for users I have created a local test harness that allows the same calls to be made from a development machine as would be made within a build or release. However, running this is not as simple was you might expect so please read the instruction before proceeding....
I have added another new feature to my Cross Platform release note generator. Now, when using Handlebars based templates you can optionally get the parent or child work items for any work item associated with build/release To enable the feature, as it is off by default, you need to set the getParentsAndChildren: true parameter for the task, either in YAML or in the handlebars section of the configuration. This will add an extra array that the template can access relatedWorkItems....