We have been looking migrating some of our common .NET Core libraries into new NuGet packages and have taken the chance to change our build process to use Azure DevOps Multi-stage Pipelines. Whilst doing this I hit a problem getting SonarQube analysis working, the documentation I found was a little confusing. The Problem As part of the YAML pipeline re-design we were moving away from building Visual Studio SLN solution files, and swapping to .NET Core command line for the build and testing of .CSproj files. Historically we had used the SonarQube Build Tasks that can be found in the Azure DevOps Marketplace to control SonarQube Analysis. However, if we used these tasks in the new YAML pipeline we quickly found that the SonarQube analysis failed saying it could find no projects ##[error]No analysable projects were found. SonarQube analysis will not be performed. Check the build summary report for details. So I next swapped to using use the SonarScanner for .NET Core, assuming the issue was down to not using .NET Core commands. This gave YAML as follows,``` - task: DotNetCoreCLI@2 displayName: ‘Install Sonarscanner’ inputs: command: ‘custom’ custom: ’tool' arguments: ‘install –global dotnet-sonarscanner –version 4.9.0 ...

Back in early 2016 I wrote an Azure DevOps Extension to wrapper Pester, the Powershell unit testing tool. Over the years I updated it, and then passed the support of it over to someone who knows much more about Powershell and Pester than I Chris Gardner who continued to develop it. With the advent of cross-platform Powershell Core we realized that the current extension implementation had a fundamental limitation. Azure DevOps Tasks can only be executed by the agent using the Windows version of Powershell or Node. There is no option for execution by Powershell Core, and probably never will be. As Pester is now supported by Powershell Core this was a serious limitation. ...

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.2634578Z Starting test execution, please wait... 2020-04-23T09:30:39.4783658Z A total of 1 test files matched the specified pattern. 2020-04-23T09:30:40.8660112Z X Can\_Get\_MIDs \[521ms\] 2020-04-23T09:30:40.8684249Z Error Message: 2020-04-23T09:30:40.8684441Z Test method PaymentServices.IntegrationTests.ControllerMIDTests.Can\_Get\_MIDs threw exception: 2020-04-23T09:30:40.8684574Z System.BadImageFormatException: Could not load file or assembly 'PaymentServices, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format. 2020-04-23T09:30:40.8684766Z Stack Trace: 2020-04-23T09:30:40.8684881Z at PaymentServices.IntegrationTests.ControllerMIDTests.Can\_Get\_MIDs() … 2020-04-23T09:30:40.9038788Z Results File: C:agent\_work\_tempTestResultssvc-devops\_SVRHQAPP027\_2020-04-23\_10\_30\_40.trx 2020-04-23T09:30:40.9080344Z Total tests: 22 2020-04-23T09:30:40.9082348Z Failed: 22 2020-04-23T09:30:40.9134858Z ##\[error\]Test Run Failed. Solution I needed to tell vstest.console.exe to run x64 as opposed to it’s default of x32. This can be done with a command line override –platform:x64 ...

I decided to create a video of my blog post ‘Swapping my Azure DevOps Pipeline Extensions release process to use Multistage YAML pipelines’. [iframe width=“560” height=“315” src=“https://www.youtube.com/embed/WMQ0G9eXczE" frameborder=“0” allowfullscreen=”" allow=“accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture”] The video up on YouTube

I have today released another enrichment to the dataset available in my Cross Platform Release Notes Azure Pipeline Task. It now returns an extra array of data that links work items and commits to build artifacts. So your reporting objects are: Array Objects workItems – the array of all work item associated with the release commits – the array of all commits associated with the release pullRequests - the array of all PRs referenced by the commits in the release ...

I recently post about Enriching the data available in my Azure DevOps Pipelines Cross Platform Release Notes Task by adding Pull Request information. Well, that first release was fairly limited only working for PR validation builds, so I have made more improvements and shipped a newer version. The task now will, as well as checking for PR build trigger, try to associate the commits associated with a build/release pipeline to any completed PRs in the repo. This is done using the Last Merge Commit ID, and from my tests seems to work for the various types of PR e.g. squash, merge, rebased and semi-linear. ...

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. Note that I have made every effort to extract variables into variable groups to aid reuse of the pipeline definition. I have added documentation as to where variable are stored and what they are used for. ...

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. You might be asked to re-authorise the link between Azure DevOps Pipelines and GitHub. Re-enter any variables that are declared via the Pipelines UI and save the changes Your pipeline should start to be triggered again ...

A common request for my Generate Release Notes Tasks is to enrich the data available beyond basic build, work item and commit/changeset details. I have resisted these requests as it felt like a never ending journey to start. However, I have now relented and added the option to see any pull request information available. This feature is limited, you obviously have to be using artifacts that linked to a Git repo, and also the Git repo have to on an Azure DevOps hosted repository. This won’t meet everyone’s needs but it is a start. ...

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. I wanted to see how easy this was to setup when you are using Azure Active Directory (AAD). ...