Introduction I have recently been swapping some Azure DevOps Pipelines to GitHub Actions as part of a large GitHub Enterprise migration. The primary tool I have been using for this is GitHub Copilot in the new Agent Mode Frankly, Copilot is like magic, it is amazing how close it gets to a valid solution. I say this after suffering years of undelivered marketing promises of no-code “we won’t need developers in the future”. ...
I have been doing some work one a Logic Apps that routes its traffic out via a vNet and accesses its underlying Storage Account via private endpoints. ‘Nothing that special in that configuration’ I hear you saying, but I did manage to confuse myself whilst testing. After changing my configuration of the vNet, I restarted the Logic App to make sure everything was working as expected on startup. The Logic App appeared to start within a few seconds, the Overview pane in the Azure Portal showing the correct values. ...
The Problem I recently was debugging an Execute PowerShell Code Logic App action, so wanted to see it’s output. However, when I reviewed the run history, the output for my code action was empty. The Cause (and Solution) The problem turned out to be that the Logic App’s Inbound traffic configuration. You can replicate this issue easily Create a new Logic App Workflow, use any trigger and then add an Execute PowerShell Code action, you don’t need to edit the default code sample. Save the new Action and then run it. Review the run history and you’ll see that the output as expected. Next, change the Logic App’s ‘Inbound traffic configuration > Public Network Access’ to ‘Disabled’ and run the Logic App again, and the output now cannot be seen, as shown above. You are actually warned about this in the Azure Portal the first time you view a run history the settings that block it ...
The Problem I recently had the need in an Azure Logic App to read a CSV file from an Azure Storage account, parse the file, and then process the data row by row. Unfortunately, there is no built-in action in Logic Apps to parse CSV files. So as to avoid having to write an Azure function, or use a number of slow, low level Logic App actions, I decided to use the PowershellCode action to parse the CSV file quickly inline with the rest of the Logic App. ...
Since moving house a couple of years ago, I have gained an ever increasing set of apps on my phone to manage various things, such the Solaredge PV and battery system we installed and our Octopus Energy account, to name but two. In the past, I had avoided IOT and the ‘Intelligent Home’ as I did not want to get to the point where ‘I can’t do the washing up, the Internet is down’. However, I recently got sent an Octopus Mini which meant for the first time I could get real time information from their API, so no longer needing to wait until my Smart Meter got around to transferring data to them, which could be up to 48 hours later. ...
Edited: 4th Feb 2025 to add detail on Azure DevOps Pipelines Service Connection Introduction When automating administration tasks via scripts in Azure DevOps in the past I would have commonly used the Azure DevOps REST API. However, today I tend to favour the Azure DevOps CLI. The reason for this is that the CLI wrappers the REST API in such a way that it is easier to use and more consistent. ...
The Issue The Azure DevOps CLI command az boards work-item update can take a list of fields as a set if value pairs e.g. az boards work-item update --id 123 --fields Microsoft.VSTS.Scheduling.Effort=10 However, if you try to replace the field name with a variable in PowerShell like this $fieldname = "Microsoft.VSTS.Scheduling.Effort" az boards work-item update --id 123 --fields $fieldname=10 you will get an error like this The –fields argument should consist of space separated “field=value” pairs. The Solution The solution is simple, and the same one required if you wish to pass multiple fields into the command, you need to wrapper the set of key value pairs for the fields in quotes e.g. ...
Background I recently wrote about the changes I had had to make to our Azure DevOps pipelines to address the changes required when code signing with a new DigiCert certificate due to new private key storage requirements for Code Signing certificates Today I had to do the same for a GitHub Actions pipeline. The process is very similar, but there are a few differences in the syntax and the way the secrets are stored. ...
This one of those posts that is more a note to self as I keep forgetting how to do this, but I hope it helps others. Background I use Microsoft’s Authenticator to provide MFA on a number of accounts. I recently swapped my Android phone and had to, after restoring a backup, re-authenticate some accounts on the new device. This was a simple process for most accounts, just a case of validating the code generated by the new device, but I had a problem with the entries where my Black Marble Entra ID account was a guest in other company’s Entra ID directories. ...
Background It is becoming increasingly important to sign files digitally to ensure that they have not been tampered with, to secure the software supply chain. This is something we have done for a good while as a step in our Azure DevOps pipelines. However, recent(ish) changes in the way certificates are issued has meant we have had to revise our approach. The Problem We used to use a .PFX file, stored as an Azure DevOps secure file, that contained the public and private keys and was accessed using a password, to sign our files. ...