TechTips

Introduction Previously Rik Hepworth has posted on ‘Importing bicep lint output as test results in Azure DevOps pipelines’. In his post he showed how you could move from using the ARM-TTK to validate ARM templates to using the built inBicep Linter. Rik’s solution involved taking the Bicep Lint output and converting it via the .SARIF format to JUnit so that it could be published to an Azure DevOps pipeline run as a set of test results....

Introduction Last year I posted on how to create your own Azure DevOps maintenance jobs. This solution has been working well for me, until the Azure DevOps Service connection’s Entra ID Service Principle secret expired. So, I thought it well worth revisiting the creation of this maintenance job but this time using Workload Identity federation to authenticate, and hence never again have to worry about the secret expiring. Updated Setup Process Note: This is a modification to the creation of the service connection, but the core the maintenance job setup remains the same as in my original post...

The Issue Whilst refreshing an end-to-end devops demo, one I use for both Azure DevOps and GitHub, I hit a problem. The new Playwright UX Tests, that were replacing old Selenium ones, were failing on the GitHub hosted runner. The strange thing was the same tests worked perfectly on: My local development machine The Azure DevOps hosted runner And strangest of all, a GitHub self hosted runner The Solution Adding some logging to the tests showed the actual issue was that on the GitHub hosted runner the code to count the rows in an HTML table was always returning 0....

The Issue I have been recently refreshing a GitHub end-to-end demo I use for talks and workshops that I had not looked at for a while. It shows how legacy code bases can be deployed with GitHub Actions and Azure App Services. The demo uses MSDeploy to deploy a ASP.NET web application to Azure App Services. The MSDeploy package is created as part of the GitHub Action workflow. The workflow uses a PowerShell script to do the deployment using the following:...

Background Our on premise build agents, though using the same image as the Microsoft hosted agents (generated using Packer, as I have previously posted about), have some extra setup done by Lability as they are deployed to a Hyper-V host. Most of this is specific to the needs of running on Hyper-V e.g. setting up networking, creating a 2nd disk to act as a working store for the build agent, and of course installing the Azure DevOps agent itself....