The Problem

I had a working pipeline that as part of its build process ran the OWASP Dependency Checker task. This can be slow to run as it has to download the current vulnerability database. To try to speed my builds I have been using the cache task to cache the current pipeline run’s downloaded vulnerability database, so on the next run the vast majority of the database is already downloaded.

The pipeline YAML is as follows

steps:
- task: PowerShell@2
    displayName: Find the NVD DB path to cache
    inputs:
    targetType: inline
    script: |
        $nvdcachepath = $(get-childitem "$(Agent.WorkFolder)\_tasks\dependency-check-build-task*\*.*.*\dependency-check\data").FullName
        echo "##vso[task.setvariable variable=nvdcachepath;]$nvdcachepath"

- task: Cache@2
    displayName: Cache NVD data
    inputs:
    key: '"NVDCache" | "$(Agent.OS)"'
    path: $(nvdcachepath)
    restoreKeys: |
        NVDCache | "$(Agent.OS)"
        NVDCache

# other build tasks

- task: JavaToolInstaller@0 
    displayName: Install Java needed for the Dependency Check
    inputs:
    versionSpec: '11'
    jdkArchitectureOption: 'x64'
    jdkSourceOption: 'PreInstalled'

- task: dependency-check.dependencycheck.dependency-check-build-task.dependency-check-build-task@6
    displayName: Dependency Check
    inputs:
    projectName: Identity Server
    scanPath: CCC.Web.IdentityAndSSO.IdentityServer
    format: HTML,XML
    additionalArguments: --nvdApiKey $(nvdapikey)

This has all been working well, but the YAML has a potential flaw, can you spot it?

The issue appeared when, due to the server that provides the OWASP vulnerability database being unavailable the dependency check task was temporarily disabled.

This meant that the dependency check task was not downloaded, so the Powershell script to find the vulnerability database folder returned an empty string as it could find no matching folder.

This is important as it is this string that controls what is cached. With no folder passed into the cache task, the whole of the pipeline working folder is cached. In effect the restoring of the cache is checking out the source as it was on the last successful build on the branch. So you are not building the commit you think you are, but an older commit, the source code that was cached.

The Solution

There are a number of options to avoid this problem

1. Don’t use the Cache task
2. Don’t disable any task that produces folders your Cache task is meant caches
3. If you disable a task who’s data you cache also disable the Cache task
4. Put some logic around the cache task e.g

   - task: Cache@2
     condition: and(succeeded(), ne(variables['nvdcachepath'], ''))
   

All are valid for different scenarios, the choice is down to your use case.

The overall point is make sure you are caching what you think you are caching, if not constrained the Cache task will cache everything it can.

Updated 30-Oct-2025 Added more details on Screen Refresh Rate and Teams Room App

The Problem

We have owned a Surface Hub v1 for a number of years, and it has served us well. However, with Microsoft ending support for Windows 10 it was in danger of becoming a large piece of sculpture in the office. This is not just because we did not want to run a Windows 10 device when security patches were not available, but that the embedded version of Teams would not even load.

In theory the answer was easy, flip a switch on the Surface Hub so it uses an external replacement PC as opposed to it’s built in one. However, this process turned out to be harder than we expected as the Surface Hub is very picky over hardware settings.

The Solution

The whole process is very well documented by Ryan Wold, so I won’t repeat the details. However, I will mention the kit and settings we ended up using as we found getting any output on the Surface Hub meant using exactly the correct settings.

We aimed to use spare kit we had around, so our replacement PC was an old Lenovo M910s desktop PC. We picked this particular unit as we had at some point in the past fitted it with an Nvidia Geforce GTX 750Ti as we knew that a dedicated GPU would be needed to drive the 4K screen.

The consistent issue we had trying to get this working was that the PC would boot, we would see the BIOS boot screen, Windows would start to load, but as soon as the loading Windows spinner appeared the Surface Hub screen would go blank. If we had a second display attached, we could see that Windows could not detect the Surface Hub as a display.

The critical item it turned out was the display one, this needed to be an active cable. We ended up with a BENFEI HDMI to DisplayPort Adapter. Once we used this some of our display issues were sorted, Windows could detect the Surface Hub consistently.

The other critical step was that we had to set the resolution to 4K (3840 x 2160) and specifically with the refresh rate set at 30Hz. If we had a more powerful GPU we think we could have run at the default rate of 120Hz, but that was not an option with the kit we had.

30Hz is not the default refresh rate when the Surface Hub is detected as a monitor, so we got the blank screen. To change the refresh rate we had to have a second display attached. This is not a problem you might think, make the edit and remove the second display. However, Windows stores the refresh rates separately for each screen setup e.g. single display, dual display etc. This meant when we disconnected the second display the refresh rate for the Surface Hub returned to its 120Hz default.

So for now we need to keep the second display attached

But not all the setup was so hard, getting the Surface Hub cameras, audio devices, touch screen and pens working was easy. All that needed was a USB cable and the right drivers

Sorting the Refresh Rate

The solution to the refresh rate issue was to use the CRU Display Utility.

With the PC running with with dual monitors:

1. Download, unzip and run the the CRU Utility
2. Selected the Surface Hub (active) display and altered the detailed resolutions order. You need the 30Hz option to be the first entry in the list
3. Repeat Step 2 for any other Surface Hub entries in the list (not sure if this step is essential, but quick to do)
4. Pressed Save and exited CRU
5. This is the important step we initially missed Use the CRU provided restart.exe tool to restart the graphic subsystem and hence read the changed order.
6. I could then disconnect the 2nd monitor, the display a rescan was done, but unlike in the past the working 30Hz refresh rate was picked.

The PC could not be rebooted, with a single monitor, and it still worked.

Trying to Setup the Team Room Client

It is good that we can now use the Surface Hub for Teams calls again, but having to login to start Teams is not as nice as being able to invite the device as location to meetings.

To try to make the device a Teams Room we download the client from the Windows App Store where it is still confusingly call the ‘Skype Team Room’. I guess it must be hard/impossible to change the name of a published package in the store. However, it is the correct one as the release history shows this app being recently updated and has the current Teams branding.

When you install and run this application it initially looks OK, but then fails saying

Microsoft Teams Room device isn’t certified

You must insert the HDMI adaptor that came with this device

You have the option to restart the application, but you get the same result.

The bottom line is that this application seems to be locked down to certified hardware, there is no option for a DIY ‘build your own unit’, or at least not one I have been able to find thus far.

Where we are now

So now we have a working replacement PC connected to Surface Hub. This PC is domain joined, so staff can login for Teams meetings and use all the physical features of the Surface Hub. This is not a perfect replacement, but it at least means the Surface Hub is not just E-Waste.

I will post again, if we have any more successes

I recently rebuild my trusty Lenovo X1 Carbon laptop. As you usually find, a fresh install of Windows 11 meant a leap in performance.

All was good for a couple of weeks, until I started to get problems. It still was working to supply power and the HDMI connection to my external monitor worked, but the USB devices could not be seen.

I also checked with the Lenovo Dock Manager and it could now no longer see the dock.

The Solution

I am not sure why it happened, but the fix was

1. Open Device Manager: Press the Windows key + X and select “Device Manager”.
2. Show Hidden Devices: Click “View” in the menu bar and select “Show hidden devices”.
3. Locate Thunderbolt Controller: Expand “System Devices” and find the “Thunderbolt Controller” entry.
4. Uninstall: Right-click on “Thunderbolt Controller” and select “Uninstall device”. In the “Uninstall Device” window, check the box that says “Delete the driver software for this device”.

Once this was done I disconnected the dock and reconnected it, and this dialog appeared

I had to approve access to the dock.

My guess is that somehow this access control setting had got set in the wrong state. I have no idea how, as I was never shown this dialog after the Windows reinstall, but at least it is fixed now

Update 14th July 2026

If this process does not work for you, or you cannot see the Thunderbolt device in the Windows Device Manager, try the following:

1. Disconnect your laptop from the dock
2. Hold down the laptop power button until your laptop switches off
3. Wait a few seconds to make sure it is off
4. Switch on the laptop
5. When it is booted, connect the dock, there is a good chance all the device and displays connected to the dock will be working

It seems the issue is that Windows 11 reboots/shutdown are not clearing some state that confuses USB-C/Thuderbolt connections. A hard reset of the electronics seems to fix it

The GitHub ‘Azure Pipelines’ App enables some really interesting ‘better together’ scenarios mixing the usage of Azure DevOps Pipelines for CI/CD processes while your source is stored on GitHub. It is particularly useful if an enterprise is migrating towards GitHub Enterprise over a period of time, maybe using GitHub Enterprise Importer (GEI) to do the migration.

I was recently working on such a migration for a client that involved numerous Azure DevOps organisations. In the past someone had setup the GitHub ‘Azure Pipelines’ App on their GitHub organisation and got it working with one of their Azure DevOps organisation.

The question was how do you setup a GitHub App based service connection in their other Azure DevOps organsations, without breaking what was already installed?

Service Connections & GitHub Authentication

The way Azure DevOps Pipelines communicate with GitHub is via a Service Connection.

To create a service connection you goto Project Settings > Pipelines > Service Connections then press the New Service Connection button, picking the service you require.

When you do this and pick the GitHub option you are offered two ways to authenticate

• A PAT - linked to a specific user and will expire after a fixed period
• oAuth - again linked to a specific user, the one creating the service connection, but will not expire, so the preferred solution

But neither of these are authentication via the GitHub App. So the question is how do you create a service connection of that type?

Solution

It turns out adding the ‘right type of service connection’ is easy, but really poorly documented. Every document seems to point to re-installing the Azure Pipelines App in GitHub, this is not required.

The process is as follows, assuming the Azure Pipeline GitHub App is installed and configured in your GitHub organisation.

1. In a Team Project on the Azure DevOps organisation where you need the service connection create a new pipeline
2. Pick GitHub as the source location. You maybe prompted to authenticate, and then will be given a list of repositories to pick from, pick one, the choice of which one is not important.
3. Once this is done you are presented with a list of pipeline templates to use, at this point you can cancel the creation of the pipeline, completing it is not required.
4. If you look in Project Settings > Pipelines > Service Connections you will see a new Git Service Connection has been created with the name of the Azure DevOps Team Project that has the authentication method GitHub App, exactly what we require.

In my scenario I was then able to rewire all the pipelines in my Azure DevOps organisation to point to GitHub using the GEI command gh ado2gh share-service-connection to share the new service connection to other Team Projects, and then gh ado2gh rewire-pipeline to change the source location.

Over the years, I have been involved in numerous migrations of TFS/Azure DevOps Server from on-premises servers to the cloud hosted Azure DevOps Services using the Microsoft Azure DevOps Data Migration Tool. As long as you carefully followed the instructions, the process was relatively straightforward.

I was recently involved in a cloud migration of a set of non-English Azure DevOps Servers i.e. the Azure DevOps Servers had been installed in French not English. Migrating these servers to Azure DevOps Services proved a challenge.

The Problem

The core of the problem with this type of migration is that the target system, Azure DevOps Services, is only available in English.

At this point it is important to explain what is meant by the previous statement. Azure DevOps Services allows you to set a language preference, which you set in your user profile, but the underlying database is always in English. This means that if you have a non-English Azure DevOps Server, where the database is non-English, the migration will have problems.

This problem becomes apparent when you perform the first step of using the Azure DevOps Data Migration Tool, the migrator validate command to validate your TPC (Team Project Collection) prior to migration.

Note Remember you migrate a TPC, not a whole Azure DevOps Server, which could have many TPCs

This command checks the source Azure DevOps Server TPC for issues that will block a migration. In the case of my Non-English server TPC the validation returned many issues.

The first was a warning about the database collation being French_CI_AS, so any migration could result in some characters not being migrated correctly e.g. Non-English characters like ‘é’ might become equivalent to the English ’e’ after migration. However, this was just a warning, and not an error, so can be ignored for now and reviewed as part of the planned dry-run of the migration.

The bigger problem was the many errors in the form

VS403443: In order to migrate successfully, you must rename field 'System.Title' to 'Title'. Given name for 'System.Title' is 'Titre'

When you do these migrations there are often VSxxxxxx or TFxxxxxx errors, especially on TPCs that have been upgraded through various versions of TFS and Azure DevOps over the years. These are usually fixable by editing the process template as discussed in the migration documentation.

However, when I tried to fix these issues I saw two completely separate sets of problems, depending on whether the TPC was using the older XML Process Templates or the newer Inherited Process Templates.

When the TPC is using XML Process Templates

When the migration was for a TPC using the older XML Process templates, I found that once I had fixed the VS403443 errors using commands like

witadmin.exe changefield /collection:http://server:8080/tfs/defaultcollection, /n:System.Title /name:"Title" /noprompt

When I reran the migrator validate command, I got a new set of errors, but they were the same errors as before, just with the field names reversed e.g..

VS403443: In order to migrate successfully, you must rename field 'System.Title' to 'Titre'. Given name for 'System.Title' is 'Title'

I was in an endless loop of errors.

When the TPC is using Inherited Process Templates

When the migration was for a TPC using the newer Inherited Process Templates, the problem was that I could not use the witadmin tool. There is in fact no supported way to update the display name for built-in work item types fields.

This is because the Inherited Process Templates are stored in the database, and not as XML files.

The Solutions

We have to consider the solutions to these problems separately.

XML Process Templates

After much unsuccessful experimentation, I reached out to the community to see if anyone had a solution to the problem and a fellow DevOps MVP, Neno Loje suggested he had had success in the past migrating TPCs originally setup in German, but the process he used came with some constraints.

The process I ended up with, based on his suggestions, was based around migrating the Non-English Team Project Collection (TPC) to an temporary English Azure DevOps Server:

1. Build a new Azure DevOps Server, making sure you pick the default language English
2. Detach the TPC to be migrated on the Non-English Azure DevOps Server and make a SQL Backup of the detached TPC Database on the Non-English Azure DevOps Server

   Note Once the backup is done, you will usually reattach the TPC on the source Non-English server so users can continue to work while you do the dryrun migration

3. Restore the TPC SQL backup on the new English Azure DevOps Server and attach the exported Non-English TPC to the new English Azure DevOps Server
4. On the new English Azure DevOps Server run the migrator validate command to check for errors, and fix them. This should be possible without getting into the error loops

   • Update all WIT fields causing the VS403443 errors, rename display names to the English names as discussed above using the witadmin command)

     Note I wrote this PowerShell script to automate the process of generating the commands to do the renaming of fields in a process template based on the migration error log.

   • Fixing any remaining errors in the migration should be possible with further XML template file edits which are published using the witadmin command as discussed in the migration documentation

     Note Watch out for any for=[group] and not=[group] attributes in the WITD XML files, used to conditionally set field constraints e.g. make a field readonly for all users except those in a specific group. These constraints are not supported in Azure DevOps Services, but are not always picked up by migrator validate. If they are not removed, they will cause the import to fail. An import failure email message will be recieved via email in form

     Step : ProcessValidation - Failure Type - Validation failed : Invalid process template: WorkItem Tracking\TypeDefinitions\Bug.xml:: Object reference not set to an instance of an object.

   • You can also look at using the ConformProject.ps1 script to help with this process. ConformProject will take a defined process template that is on your local machine and apply it, in full, to a specified project. This is a good way to get rid of all the errors, but you will lose all your customisations, so use with care.

5. Once all the errors are fixed, the validation should pass, and hence the rest of the migration process should be possible

However, the fact your migration completed might not be the end of your issues. There is of course the potential issue of the collation of the database, but arguably this is a minor issue. The more important point is something Neno had mentioned. He commented that this process is good for a read-only migration to Azure DevOps Services, but if you wish to continue using the migrated work items more work is required.

The reason for this is not the migration of the process template, it’s the actual work item data. The imported work items are still using strings for state and other fields in the non-English language and need to be “converted” to values that match the constraints of the ‘fixed’ english process template.

To fix this means edits are required for all active work items. This of course could be done one-by-one as Work Items are edited, or via scripts to make the changes at scale, but more the work will be required to make the work item data usable in Azure DevOps Services.

Inherited Process Templates

—— DANGER ZONE ——

The following section describes a process that is not supported by Microsoft and could lead to serious issues with your Azure DevOps Server.

The process should only be used on a copy of a system, not on a live system itself.

I accept no responsibility for any issues that arise from following this process, you follow it at your own risk.

When the migration was for a TPC using Inherited Process Templates, the solution is very different, and can only be described as a massive hack.

There are two reasons for the need for a different process

• With inherited process templates the built-in work item types are by design read only. Your customisations are additions to the built-in work item types. You cannot change the built-in work item types, you can only hide or add new fields to them. There is no equivalent of the witadmin command to change the display names of fields in the Inherited Process Templates, all changes are done via the Azure DevOps UI or REST API.
• The other reason for the different process is that it is not possible to attach a Non-English Inherited Process TPC to an English Azure DevOps Server. Any ‘fixing’ process must be done on a Non-English server.

So, the process I ended up with is as follows:

1. IMPORTANT Create a duplicate of your Non-English Azure DevOps Server, this is the one you will use for the migration process. This step is very important, as you will be making SQL edits to the database which is very unsupported.
2. On the duplicate Non-English Azure DevOps Server load SQL Server Management Studio (SSMS) and connect to the TPC database.
3. For each VS403443 error run the following SQL command to update the display name of the field in the database:

   UPDATE [dbo].[WorkItemTypeField]
   SET [Name] = 'Title',
       [ReportingName] = 'Title'
   WHERE [ReferenceName] = 'System.Title'
   

   Note Again I wrote a PowerShell script to automate the process of generating the SQL commands to do the renaming of fields in a process template based on the migration error log.

4. Rerun the migrator validate command to check for any remaining errors, and fix them.
5. Once all the errors are fixed, the validation should pass, and hence the rest of the migration process should be possible

Again the fact your migration completed is not the end of your issues, in fact the issues are much worse than with the XML Process Templates.

The reason for this is that the Non-English inherited process template tries to match all your work items to the built-in work item types based on the string of the work item type name. So for example, it will try to match the work item type ‘Bogue’ in your French team project to the built-in work item type ‘Bug’, which will of course fail.

This is a serious problem, as it means much of the Azure Boards and Azure Test Plans UI will fail to load any work items, if they even load at all. The work item data is there, you can see it via the REST API e.g. https://dev.azure.com/{organization}/{project}/_apis/wit/workitems/{id}, but the UI will not work as the work item type names are not what the English based Azure DevOps Services instance is expecting.

In theory there must be a way to fix this, but it will require a lot of SQL edits prior to migration to Azure. Far more work than I have the appetite to do.

So in summary, you have to consider this process for migrating Non-English inherited process based TPCs to only be acceptable if your key goal is to migrate your TFVC repositories with no data loss to Azure DevOps Services, and that you are prepared to accept that the work item data will not be usable.

Your only real option if you need the work item data from a Non-English on-premises Inherited process TPC in Azure DevOps Services is to look at using Martin Hinshelwood Azure DevOps Migration Tools to migrate the on-premises work items to a new Azure DevOps Services project on the migrated Azure DevOps Service instance, one that is setup using an English based inherited process template. Given the need to address translation issues during this migration this will also be a not insignificant undertaking.

Conclusion

Migrating a non-English Azure DevOps Server to Azure DevOps Services is possible, but it is not officially supported and requires some extra steps, some of them very ‘hacky’.

If you are considering either of the migration paths in this post, I would recommend in the strongest terms that you perform your migrations on a duplicate of your Azure DevOps Server and not on your live system.

I cannot stress enough, please DO NOT make SQL edits of your live Azure DevOps Server database, as this is not supported and could lead to serious issues with your live system.

I got asked today by a client if there was a way to automate the exporting Azure DevOps Test Plans to Excel files. They knew they could do it manually via the Azure DevOps UI, but had a lot of Test Plans to export and wanted to automate the process.

The Options

I considered a few options:

• TCM CLI - This is a command line tool that can be used to interact with Azure DevOps Test Plans. It can be used to import or clone Test Plans, but not to export them.
• AZ DEVOPS CLI - This is a command line tool that can be used to interact with Azure DevOps. Unfortunately, it does not have any commands to export Test Plans.
• Azure DevOps REST API - This is a powerful API that can be used to interact with Azure DevOps, but the documentation makes no mention of a call to export Test Plans.

But…..

The Solution

I used a process I have used before to write tools for Azure DevOps. I opened the page in the Azure DevOps UI that I wanted to automate, and then used the browser developer tools to inspect the network traffic. I found a call that was made to export the Test Plan to Excel, and then used that as the basis for my tool.

Turns out there is an undocumented API call that can be used to export Test Plans to Excel. A POST call is made to the following URL:

https://dev.azure.com/{organization}/{project}/_apis/testplan/TestCases/TestCaseFile?api-version=7.1-preview.1

with a payload that looks like this:

{
  "testPlanId": 1,
  "testSuiteId": 2,
  "testCaseIds": [3, 4, 5],
  "columnOptions": ["System.Id","System.AssignedTo","System.State"]
}

The Code

So I needed to write a tool get all the test plans and test suites in an Azure DevOps Team project, and then call the API to export them to a set of Excel files.

I usually write this type of tool in PowerShell, but try as I might, even though I appeared to get the expected data back from the API call, I could not write it to disk in such a way Excel could read it. Excel said the file was corrupt.

As I had delivered a webinar today on using GitHub Copilot to write code, I thought I should practice what I preach and use it to fix the tool. As I suspected the issue was not the API call, but the PowerShell encoding of the data, I decided to ask Copilot to convert the code to Python, a language I am not too familiar with.

So with a couple of prompts my simple PowerShell proof of concept was converted to a Python script, and as I had hoped the resultant saved file loaded in Excel without a problem.

It was then a simple matter of adding more code, via Copilot prompts, to loop through all the Test Plans and Test Suites in the Team Project, and then call the API to export them to a set of Excel files.

This is not to say I did not have to make some tweaks to the code, but Copilot got most of it correct, there were a couple of edits I had to make to API URL strings, but Copilot certainly wrote the Python code much faster than I could have done myself.

So certainly a win for GitHub Copilot, and I now have a tool that can be used to export Azure DevOps Test Plans to Excel files at scale.

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

Thats said, I have yet to find a Copilot translated GitHub Action workflow that works 100% first time. Interestingly they often run without error, but don’t have the desired results of the source pipeline.

So what have I learnt?

Your prompts will not be as ‘definitive’ as you think.

Many steps done using Azure DevOps tasks have no obvious 1-to-1 equivalent in GitHub Actions, so Copilot generates script blocks to perform the same function.

I was moving an Azure DevOps YAML pipeline that was targeting Ubuntu to GitHub Actions, so not unreasonably the generate scripts were in BASH. The problem for me was that I don’t have that much BASH experience, so making my debugging slower.

The solution in my case was as simple as to add an initial prompt stating any generated scripts should be in PowerShell Core, or as I did, use subsequent prompts to alter the generated scripts.

Note If you always want given prompt to be present, such as to favour PowerShell in a given repo, the you could look at adding a .github/copilot-instructions.md file to define prompts that are added to everything.

Silent errors are the root of many issues

Most of the problems I had with migrated pipelines were the ones you experience in any CI/CD solution i.e. you are in the wrong folder, a filter is wrong, the built URI is incorrect etc.

Using Copilot for this migration, these types of errors seemed to be caused by either

• the move from Azure DevOps tasks, that may have hidden behaviors or defaults, to scripts
• or the differences in CLI tools called between the tasks and generated scripts

I good example was the way an archive/ZIP step worked. I ended up creating a ZIP file of static website content with an extra root folder, so all other folders were one level deeper than expected. This deployed without error, but obviously did not work as the old site content had not been overwritten, all the new content was in a sub-folder. A simple problem, but one that took me too lon to realised what the cause was as I got no error messages.

Summary

GitHub Copilot can get you 90% plus of the way to a solution, but as with all coding the ‘devil is in the detail’. That last few percent will take a disproportionate time.

Also there is the danger it generates code you don’t understand, but that is a learning opportunity is it not?

That said, with careful crafting of your prompts you get a better solution faster, as long as you don’t relax the quality checks you should be doing for any solution whether human or AI created.

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.

However, if I tried to access any of the workflows in the Logic App, I was presented with a ‘bad gateway’ error. On receiving this error, I assumed that I had made a mistake in the configuration of the vNet and started to investigate.

However, I should not have been so hasty. After waiting a minute or two, the Logic App started to work as expected. It appears that the Logic App Overview pane is updated long before the Logic App is fully operational,so can’t be trusted as a source of truth.

So not a revelatory blog post, but a reminder to myself to be patient when restarting Logic Apps.

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

1. 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.
2. Save the new Action and then run it.
3. Review the run history and you’ll see that the output as expected.
4. 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

But it is easy to miss, or as I did, just forget about the limitation.

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.

The documented code sample suggests the following should work

# Retrieve outputs from prior steps
$csvdata = Get-ActionOutput -ActionName FileContent

$rows = $csvdata | ConvertFrom-csv

# Push outputs forward to subsequent actions
Push-WorkflowOutput -Output $rows

However this resulted in a null value for $rows.

The Solution

The problem turned out to be that the getFileContentV2 action that I used to load the file from Azure storage, returned the file content as part of an object, not as a simple string. So I had to request the correct property from the object.

# Retrieve outputs from prior steps
$action = Get-ActionOutput -ActionName FileContent
$csvdata = $action.outputs['body'].ToString();

$rows = $csvdata | ConvertFrom-csv

# Push outputs forward to subsequent actions
Push-WorkflowOutput -Output $rows

Once this change was made, the CSV file was parsed correctly and I was able to process the data as required.

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.

So I thought it time to look at unifying the management of all these systems, and potentially automating some behaviors such as switching things on or off based the current cost of power and the performance of our PV/Battery system.

So enter Home Assistant, an OSS project I had heard very good things about, and I have to say lived up to the hype.

The installation was very easy, I used an old Intel NUC PC I had lying around.

Once running on my home network, Home Assistant automatically detected far more devices than I had expected. These included an LG TV, AudioCast devices, a old NetGear NAS, and a good few more. Very impressive, using only ‘standard device integrations’ shipped in the basic Home Assistant install, and no additional configuration by me.

Connecting to Octopus Energy and Solaredge took a bit more work as these integration were not shipped as standard.

First, I installed Home Assistant Community Store (HACS). This allows you to easily install any community Home Assistant add-in hosted GitHub. Once this was in place I could install community integration for Octopus Energy and Solaredge Modbus.

Note There is a Solaredge device integration shipped with Home Assistant, but it queries the Solaredge web-hosted API and not the local device, so any data is 15-30 minutes out of date. The community Modbus version queries the Solaredge inverter directly over Ethernet, so provides real time data. Much for useful if planning to do home automation based on current conditions.

Again, this was all very easy, a few clicks and they were installed. The only complexity, where I had to do some reading and learning, was getting the correct data for Home Assistant Energy Dashboard (shown above). This was because the Solaredge Modbus integration provides a lot of low level raw data, but not all the values the Energy Dashboard needs.

However, as I was learning to expect for Home Assistant, the solution was well documented in the Solaredge Modbus integration GitHub Project WIKI. To use Sensor Templates to process the raw data to the forms needed. With hindsight, having to work my way though configuring this was an excellent way to learn Home Assistant better. I find it is always better to learn by trying to fix a problem you are experiencing, rather than just following tutorials

So, my Home Assistant is up and running. It is great to see such a successful and well documented OSS project with a large community of contributors. I am looking forward to seeing what else I can do with Home Assistant, but still fear I am on the slippery slope to being ‘unable to do the washing up due to an Internet outage’.

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.

One of the most noticeable advantages is in the area of authentication. The CLI supports a number of authentication methods that are not directly available to the REST API.

In this post, I will explore the options available to authenticate the Azure DevOps CLI.

Authentication Options

The Azure CLI has a login command az login, but so does the Azure DevOps extension az devops login. We have the option to use either depending on what we are are trying to do.

The key thing to considers is scope, whether you are trying to autenticate with the whole an Azure subscription or just an Azure DevOps instance.

Azure CLI Personal Access Token (PAT)

PATs have historically been the usual means to authenticate with Azure DevOps . They are still perfectly valid, and the easiest way to authenticate for command line usage. However, it is worth noting that Microsoft are now recommending a move away from PATs.

The basic command to use a PAT is az devops login, when this is run you will be prompted for your PAT.

A script can build on this authentication mechanism and allow the PAT to be passed into the script by echoing it into the az command.

echo  "<my-pat>" | az devops login --organization "https://dev.azure.com/myorg

Interactive Login using Entra ID

An alternative to using a PAT is to login to the Azure CLI using your corporate ID that has access to your Azure Subscription. This can be done outside of any script by using the az login command prior to running the script, or making this command the first one in the script.

When the az login command is run, if it can, it will launch a browser allowing you to authenticate via Entra ID using your corporate ID. Once done, your session will be valid for a period of time, and you can use any az commands.

If a browser is not available, the az login command initiates the device code flow and instructs the user to open a browser page at https://aka.ms/devicelogin on another device. Then, enter the code displayed in the terminal. This flow can be forced by using the command

 az login --use-device-code

The problem both those mechanisms that they are not suitable for a script that needs to run unattended, as they requires a user to be present to authenticate.

Using a Service Principle

A Service Principle is an application registration within Entra ID.

In Azure DevOps, a Service Principle can be granted access to an Azure DevOps Organisation and Projects as you would a user account i.e. the Service Account can be granted a license and given permissions inside a project.

You can create a Service Principle using the command

az ad sp create-for-rbac --name myServicePrincipalName1 --role reader --scopes /subscriptions/00000000-0000-0000-0000-000000000000 

Note: The Service Principle must have at least the role of ‘reader’ in the Azure Subscription associated with the Entra ID

When the above command is run, the result will be block of JSON including an appId, password and tenantID. These values should be stored securely

Once the Service Principle has been created you can grant it permissions to the Azure DevOps Organisation and Projects as needed.

Finally, using the securely stored values, you can now authenticate with the Azure ClI using the form

az login --service-principal -u <appID> -p <password> --tenant <tenantid>

Unlike the interactive login, if you use this mechanism you have the option to pass these values into a script as parameters. So can be used for unattended scripts.

The issue with this mechanism is that the password will expire, and has to be renewed. So there is a maintainance overhead.

Managed Identity

The final option is to use an Azure Managed Identity.

A Managed Identity is created as a resource in Azure. Like a Service Principle, a Managed Identity can be granted a license and permissions in Azure DevOps.

To login with a Managed Identity on an Azure hosted VM you can use the command

az login --identity

This works because the Managed Identity must be associated with the Azure VM you are running the az command on.

The need to be on an Azure resource is the limitation of Managed Identities. So are not appropriate to your needs if you wish to run your script, that uses the Azure CLI, from locations outside Azure.

So what do I use?

My most common use-case is to run a script that uses the AZ CLI from within an Azure DevOps Pipeline. This requirement gives need to two ways of working.

When I need to access an Azure Subscription

If my script needs permissions beyond Azure DevOps, interacting with a range of Azure resource in a subscription. I could create a Service Principle and grant it permissions to the required resources in Azure, and then pass the Service Principle values into the script as parameters from secret Azure DevOps Pipeline variables.

However, that is a lot a work, and there is a better option built into Azure DevOps, Service Connections. When you add an ‘Azure Resource Manager’ service connection you are able to pick from a variety of options such as App Registration (Service Principle), or Managed Identity. Most of the options availble automatically create the required Azure resources required and can support workload identity federation so you don’t have to worry over expiring secrets.

You can then very easily run your scripts on a pre authenticated PowerShell session using the AzurePowerShell task

- task: AzurePowerShell@5
  displayName: Run a Script against Azure Resources
  inputs:
    azureSubscription: 'MyServiceConnection'
    azurePowerShellVersion: 'LatestVersion'
    ScriptType: 'InlineScript'
    Inline: |
      # your az commands, not need to login as it is already done
      az ....
    FailOnStandardError: true
    pwsh: true

When I only need to access Azure DevOps

However, my scripts commonly only need to interact with Azure DevOps, and in this case I just use the Build Agent token as a PAT. This is because it avoids the need to set anything up, you can easily pass the token into the script as an environment variable.

trigger: none

pool:
  vmImage: ubuntu-latest

steps:
- task: PowerShell@2
  displayName: 'Increment PBI count'
  inputs:
    targetType: 'inline'
    pwsh: true
    script: |   
      # I don't need to call az login as it done automaticallly
      az devops ....
  env:
    AZURE_DEVOPS_EXT_PAT: $(System.AccessToken)

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.

$fieldname = "Microsoft.VSTS.Scheduling.Effort"
az boards work-item update  --id 123 --fields "$fieldname=10"

Once this is done the command will work as expected.

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.

The Solution

Step 1: Create a Composite Action

I stored theses steps as a Composite Action for easier reuse, but you could put them within a workflow if you prefer.

The composite action installs the DigiCert tools in the first step, and then finds and signs the files in the second.

Yes, I know I could just have a single step, but I wanted to follow the Azure DevOps flow as closely as possible.

name: 'Sign Code with DigiCert'
description: 'Signs the contents of a folder with DigiCert'
inputs:
  digicert-api-key: 
    description: 'The DigiCert API key'
    required: true
  tools-download-url:
    description: 'The URL for the DigiCert Windows MSI'
    required: false
    default: https://one.digicert.com/signingmanager/api-ui/v1/releases/smtools-windows-x64.msi/download
  signer_p12_file: 
    description: 'The DigiCert Signer P12 File as base64 encoded string'
    required: true
  cert_crt_file:
    description: 'The DigiCert Certificate CRT File as base64 encoded string'
    required: true
  digicert_host:
    description: 'The DigiCert Host'
    required: false
    default: https://clientauth.one.digicert.com
  keypair_alias:
    description: 'DigiCert certifiate alias'
    required: true
  password:
    description: 'Digicert password'
    required: true
  file-path:
    description: 'Path to scan for files'
    required: true
runs:
  using: "composite"
  steps:
  - name: Install DigiCert Client Tools
    shell: pwsh
    run: | 
      curl -X GET  ${{ inputs.tools-download-url }} -H "x-api-key:${{ inputs.digicert-api-key }} " -o smtools-windows-x64.msi 
      msiexec /i smtools-windows-x64.msi /quiet /qn 

  - name: Code Sign Files
    shell: pwsh
    run: |
      # Define the base path where signtool.exe is located
      $basePath = "C:\Program Files (x86)\Windows Kits\10\bin"
      # Filtering via version and architecture, could use just one of the these, depends on needs
      $preferredVersion = "x64"

      # Get the matching signtool path (pick the last in the list if multiple returned)
      $signtoolPath = (Get-ChildItem -Path $basePath -Recurse -Filter "signtool.exe" -File | Where-Object { $_.FullName -like "*\$preferredVersion\*" })[-1] | Select-Object -ExpandProperty FullName
      write-host "Found signtool at $signtoolPath"
      
      set-content -Path 'signer.p12.base64' -Value '${{ inputs.signer_p12_file }}' 
      certutil -decode -f 'signer.p12.base64' 'DigiCert Signer Certificate_pkcs12.p12'

      set-content -Path 'cert.crt.base64' -Value '${{ inputs.cert_crt_file }}' 
      certutil -decode -f 'cert.crt.base64' 'cert.crt'

      # Find the files that match 
      write-host "Finding files that match'the path ./src/sample/bin/**/**/*.dll"
      Get-ChildItem -Path "${{ inputs.file-path }}" | ForEach-Object {
        $filePath = $_.FullName
        write-host "Signing file $filePath"
        & $signtoolPath sign /v /tr http://timestamp.digicert.com /td SHA256 /fd SHA256 /csp "DigiCert Signing Manager KSP" /kc "${{ inputs.keypair_alias}}" /f "cert.crt" $filePath
      }   
    env:
      SM_HOST: ${{ inputs.digicert_host }} 
      SM_API_KEY: ${{ inputs.digicert-api-key }} 
      SM_CLIENT_CERT_PASSWORD: ${{ inputs.password }} 
      SM_CLIENT_CERT_FILE: DigiCert Signer Certificate_pkcs12.p12
      SM_TLS_SKIP_VERIFY: true

Step 2: Store the Certificates as Secrets

As with Azure DevOps implementation we now have a pair of files, the .CRT certificate and the .P12 signer’s certificate.

GitHub does not have a feature like Azure DevOps Secure Files. So, we have to store the certificates as secrets.

To store these certificates as GitHub Secrets you need to encode the file content into a base64 string and then add it as a secret in your GitHub repository, or Organisation or Enterprise. Use whichever level works best for you, in my case I chose to store them as Organisation secrets.

Here are the steps:

1. Open Command Prompt or PowerShell.
2. Use the certutil command to encode the file:

   certutil -encode yourfile.crt yourfile.crt.base64
   

3. Open the generated yourfile.crt.base64 file in a text editor (e.g., Notepad) and copy its content.
4. Add the secret to GitHub at the level you chose:
   • Name your secret (e.g. CRT_FILE).
   • Paste the base64-encoded content into the Value field.

Repeat this process for both the .CRT and the .P12 file.

Step 3: Store the other DigiCert settings as secrets and variables

The other DigiCert settings can be stored as a mixture of secrets and variables. Use variables if reading the value in the log is not deemed a security risk.

The secrets:

• DIGICERT_API_KEY
• DIGICERT_SIGNER_P12_FILE as base64 encoded string (see above)
• DIGICERT_CERT_CRT_FILE as base64 encoded string (see above)
• DIGICERT_CLIENT_CERT_PASSWORD

and as a variable:

• DIGICERT_KEYPAIR_ALIAS

Step 4: Using the Composite Action in a Workflow

Finally pull it all together in your workflow

 - name: Sign files with Digicert
   uses: blackmarble/Sign-Code-With-DigiCert@v1
   with:
     digicert-api-key: '${{ secrets.DIGICERT_API_KEY }}'
     signer_p12_file: '${{ secrets.DIGICERT_SIGNER_P12_FILE }}'
     cert_crt_file: '${{ secrets.DIGICERT_CERT_CRT_FILE }}'
     keypair_alias: '${{ vars.DIGICERT_KEYPAIR_ALIAS}}'
     password: '${{ secrets.DIGICERT_CLIENT_CERT_PASSWORD }}'
     file-path: './src/Sample/bin/**/**/*.dll'

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.

I could not remember the process.

The Solution

When the Authenticator app shows the message

Action Required

Scan the QR code provided by your organization to finish recovering your account

and the account is in the form richard_domain.com#EXT#@anothercompany.onmicrosoft.com

The steps are as follows (assuming you still have access to the old MFA device):

1. In a browser open https://mysignins.microsoft.com/security-info
2. Sign in with your own company Entra ID account i.e. in this example richard@domain.com
3. Click the ‘organisation’ button (a icon of a directory tree, in the top right near the help button).
4. A list of organisations you are a member of will appear as a panel on the right of the page
5. Pick the required organisation from the menu on the right, in my richard_domain.com#EXT#@anothercompany.onmicrosoft.com example, this would be an organisation called anothercompany
6. You will need to authenticate with the old MFA device
7. On the refreshed https://mysignins.microsoft.com/security-info page for the selected organisation you can now use the add a new device process to generate the QR code
8. On the new MFA device pick the account to be re-authenticate and scan the QR code. This is all that is required to add the new device as sign-in method (note you do not have to completed the new device wizard in the browser, but it is probably a good idea as a final check.).

If you don’t have access to the old MFA device, you will need to contact the organisation’s IT support to get them to reset the MFA for you.

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.

However, when we renewed our code signing certificate with DigiCert we found this approach no longer valid due to new private key storage requirements for Code Signing certificates.

The basic issue is that now when we sign a file, the signing tool needs to make a call back to a secure location to validate the certificate. In our case Digicert’s Keylocker service.

The Solution

This change required some changes to our pipelines.

1. Store our .CRT certificate file as a secure file in Azure DevOps
2. Store our .p12 signer’s certificate file as a secure file in Azure DevOps
3. Store our DigiCert account settings as Azure DevOps pipeline variables (a mixture of standard and secret ones)
4. Update our pipeline as follows

- task: SSMClientToolsSetup@1
  displayName: Install DigiCert Client Tools 

- task: DownloadSecureFile@1
  displayName: Download DigiCert Code Signing Certificate File
  inputs:
    secureFile: 'DigicertCodeSigningCert.crt'

- task: DownloadSecureFile@1
  displayName: Download DigiCert Signer Certificate File
  inputs:
    secureFile: 'DigiCertSignerCertificate.p12'

- task: PowerShell@2
  displayName: Code Sign Files
  inputs:
    targetType: 'inline'
    script: |
      # Define the base path where signtool.exe is located
      $basePath = "C:\Program Files (x86)\Windows Kits\10\bin"
      # Filtering via version and architecture, could use just one of the these, depends on needs
      $preferredVersion = "x64"

      # Get the matching signtool path (pick the last in the list if multiple returned)
      $signtoolPath = (Get-ChildItem -Path $basePath -Recurse -Filter "signtool.exe" -File | Where-Object { $_.FullName -like "*\$preferredVersion\*" })[-1] | Select-Object -ExpandProperty FullName

      # Find the files that match filter that need to be signed
      write-host "Finding files to sign"
      Get-ChildItem -Path "$(Build.SourcesDirectory)/myproject/**/*.exe" | ForEach-Object {
         $filePath = $_.FullName
         write-host "Signing file $filePath"
         & $signtoolPath sign /v /tr http://timestamp.digicert.com /td SHA256 /fd SHA256 /csp "DigiCert Signing Manager KSP" /kc "$(SM_KEYPAIR_ALIAS)" /f "$(Agent.TempDirectory)\DigicertCodeSigningCert.crt" $filePath
       }   
   env:
     SM_HOST: $(SM_HOST) 
     SM_API_KEY: $(SM_API_KEY) 
     SM_CLIENT_CERT_PASSWORD: $(SM_CLIENT_CERT_PASSWORD) 
     SM_CLIENT_CERT_FILE: $(Agent.TempDirectory)\DigiCert Signer Certificate_pkcs12.p12
     SM_TLS_SKIP_VERIFY: $(SM_TLS_SKIP_VERIFY)

The gotcha with variables

I have blogged a number of times before about the need to be careful with the syntax for Azure DevOps variables. Guess what, I got caught out by this again!

I had initially used the ${{ variables.XXX }} format for injecting the Azure DevOps variables as PowerShell environment variables e.g.

 SM_HOST: ${{ variables.SM_HOST }}
 SM_API_KEY: ${{ variables.SM_API_KEY }}

This worked fine for the standard variables, but not for the secret ones. The secret ones were not being injected into the script as environment variables so when we tried to sign a file we got the error

SignTool Error: No private key is available.

This was a case of trying to be too clever with the syntax, the correct syntax in this case is to use the standard macro syntax $(XXX) format for all variables, especially the secret ones.

 SM_HOST: $(SM_HOST)
 SM_API_KEY: $(SM_API_KEY)

Once this was done, the signing process worked as expected.

Every project is different, and sometimes you need to be able to inject a step into the Web Deploy package creation process to complete some extra step. This can be done by adding a target to the .csproj project file.

The following example shows how you could sign the assemblies before the Web Deploy package is created.

 <Target Name="SignWebExe" AfterTargets="GenerateMsdeployManifestFiles" BeforeTargets="PackageUsingManifest" Condition="'$(Configuration)' == 'Release'">
    <PropertyGroup>
      <Cmd>signtool.exe sign /debug /f "$(certPath)" /p "$(certPassword)" "$(ProjectDir)obj\$(Configuration)\Package\PackageTmp\bin\MyNamespace*.dll"</Cmd>
    </PropertyGroup>
    <Message Text="Signing web deploy executable with command: $(Cmd)" />
    <Exec Command="$(Cmd)" />
  </Target>

The required parameters for this extra step are then passed in as MSBuild arguments. For example, in an Azure DevOps pipeline, you could use the following task:

- task: VSBuild@1
displayName: 'Build Core Services Solution'
inputs:
    solution: src/MySolution.sln
    msbuildArgs: '/p:DeployOnBuild=true;PublishProfile=Release /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:DeployIisAppPath="__SITENAME__" /p:certPassword="$(SigningPassword)" /p:certPath="$(SigningCertFilePath)"'
    platform: '$(BuildPlatform)'
    configuration: '$(BuildConfiguration)'
    clean: true

We are running our SonarQube instance as an Azure hosted Docker container.

Over the past few weeks we have been seeing intermittent occurrences of the ProjectFileIndexer exception during the SonarQube analysis step in our Azure DevOps pipelines.

##[error]java.lang.IllegalStateException: Unable to load component class org.sonar.scanner.scan.filesystem.ProjectFileIndexer

When I looked closer at the exception stack, I could see at the bottom there was always a timeout error when trying to access the project.protobuf file from SonarQube.

Caused by: java.lang.IllegalStateException: Fail to request url: https://sonarqube.mydomain.co.uk/batch/project.protobuf?key=mykey

If I tried to open the URL in a browser, authenticated with SonarQube, most of the time the expected project.protobuf file was returned, but sometimes it was not.

Also, at random times, the SonarQube UI would take many seconds to refresh when I selected a project.

The Solution

In the past I have usually found any issues with SonarQube are ElasticSearch related, but not so this time.

The issue turned out to be a lack of SQL resources.

Our SonarQube instance was running on

• Azure Web App (Premium V3 P1V3 2vCPU & 8Gb)
• Azure SQL DB (Standard S2 50 DTU)
• Logs/Config/ES indexes etc/ on Azure Standard General Purpose V2) File storage

When I look at the Azure SQL Query Performance Insights, I could see that the SQL DTU resources were maxing out at 100% for long periods of time, this occurred especially when the SonarQube analysis was restarted.

I increased the SQL resource to a Standard S3 100 DTU, the scaling took 15 minutes or so. Once this was done, the issue seemed to be resolved, though it is always hard to be sure with intermittent issues.

My assumption is that there are some SQL queries that are slow to run and are potentially blocking to other queries. By increasing the SQL resources, the these queries could be processed more quickly, and the blocking reduced to a level where it was not an issue.

You can see the impact of the change in the SQL DTU usage graph below. After the increase in SQL resources, we are not maxing out the server DTUs, so the SonarQube analysis can running without issues.

I think the key take away is to make sure you have enough SQL resources, don’t max out your assigned DTUs, as this will cause issues.

As I have blogged previously, we run a SnipeIT instance to manage our IT assets, hosted in Azure using Docker.

This has been working well for us for the past year, but recently we have noticed that the system has become very slow to respond.

Looking on the Azure portal, we can see that around the 15th of October the web app’s response times have gone from milliseconds to 10s of seconds

Investigation

The first question we asked, as you always should, was what had changed?

The answer was nothing obvious.

• We had not changed the Azure Web App or MySQL SKUs
• It is true that we had not updated the SnipeIT version since July, but we were on the current major and minor version and only a few patch versions behind.
• We had not added any significant new assets or users in the last few months.

So it all appeared strange what had changed?

We of course tried restarting the container instance, and cleaning down logfiles. We have seen slow performance in other systems when the logfiles get too large.

We also tried upping the SKU of the Azure Web App, but none of this made a difference.

We then set the SnipeIT log level to debug, this showed the high response times were not due to the web app being slow to respond, but the time taken to get data from the MySQL instance.

Looking again at the metrics in the Azure portal, I noticed that the MySQL instance started showing a higher CPU usage and increased DB connections around the same time as the web app started to slow down.

These new CPU and connection levels did not seem excessive, but they were higher than they had been previously. I then noticed in the Azure Portal a warning message, that we had used up all the MySQL Burstable SKU credits.

Solution

The solution was in fact simple, to move the MySQL instance to a higher SKU, from Standard_B1s to Standard_B2ms, increasing the running cost by only a few pence a month, from £2.17 to £2.25 PCM

This SKU change doubles the resources available to MySQL, but more importantly allows us to build up more burstable CPU credit for the times we need it in a month.

So now I have a working solution, it as all down to the fact that we had been running close to the limit of our MySQL SKU for a while, and it was a matter of time before the issue occurred.

If you are using staged deployment in Azure DevOps, you will probably have multiple Azure Service Connections. So, it makes sense that you might want to use a Service Connection name that is stored in a variable group as a parameter to a templated YAML pipeline.

# the build pipeline
stages:
  - stage: UAT
    jobs:
    - deployment: ARM_Provisioning
      timeoutInMinutes: 0
      environment: 'Staging'
      variables:
      - group: UAT
      pool:
        vmImage: 'windows-latest'
      strategy:
        runOnce:
          deploy:
            steps:
            - template: YAMLTemplates\ProvisionUsingARM.yml
              parameters:
                AzureResourceGroup: $(AzureResourceGroup)
                AzureServiceConnection: $(AzureServiceConnection)
  - stage: PROD
    jobs:
    - deployment: ARM_Provisioning
      timeoutInMinutes: 0
      environment: 'Staging'
      variables:
      - group: PROD
      pool:
        vmImage: 'windows-latest'
      strategy:
        runOnce:
          deploy:
            steps:
            - template: YAMLTemplates\ProvisionUsingARM.yml
              parameters:
                AzureResourceGroup: $(AzureResourceGroup)
                AzureServiceConnection: $(AzureServiceConnection)

With a template YAMLTemplates\ProvisionUsingARM.yml that uses the AzureServiceConnection variable

parameters:
- name: AzureResourceGroup
  type: string 
- name: AzureServiceConnection
  type: string

- task: AzureResourceManagerTemplateDeployment@3
  displayName: 'Azure Deployment: Create Or Update Resource Group'
  inputs:
    deploymentScope: 'Resource Group'
    azureResourceManagerConnection: '${{ parameters.AzureServiceConnection}}'
    action: 'Create Or Update Resource Group'
    resourceGroupName: '${{parameters.azureResourceGroup}}'
    ...

The Issue

If I declared a pair of variables in the UAT and PROD variable groups with the names AzureServiceConnection and AzureResourceGroup I would expect each stage to pick up the appropriate variable group and use the correct service connection.

However, this is not the case. The pipeline will fail with the following error message when you validate or try to queue the pipeline.

There was a resource authorization issue: “The pipeline is not valid. Job ARM_Provisioning: Step input azureResourceManagerConnection references service connection $(AzureServiceConnection) which could not be found. The service connection does not exist, has been disabled or has not been authorized for use. For authorization details, refer to https://aka.ms/yamlauthz."

Basically, the $(AzureServiceConnection) variable is not being expanded during template validation.

Analysis

Compile and Runtime variables

I tried all the options for the variable declaration in the YAML

• Standard Macro format $(AzureResourceGroup)
• Expression format $[AzureResourceGroup]
• Runtime expression format ${{ variables.AzureResourceGroup}}

None of these helped.

Hardcoding the connection name

If you hardcode the service connection name in the outer YAML pipeline file, the pipeline will work as expected.

# the build pipeline
  - stage: UAT
    jobs:
    - deployment: ARM_Provisioning
      timeoutInMinutes: 0
      environment: 'Staging'
      variables:
      - group: UAT
      pool:
        vmImage: 'windows-latest'
      strategy:
        runOnce:
          deploy:
            steps:
            - template: YAMLTemplates\ProvisionUsingARM.yml
              parameters:
                AzureResourceGroup: $(AzureResourceGroup)
                AzureServiceConnection: UAT
  - stage: PROD
    jobs:
    - deployment: ARM_Provisioning
      timeoutInMinutes: 0
      environment: 'Staging'
      variables:
      - group: PROD
      pool:
        vmImage: 'windows-latest'
      strategy:
        runOnce:
          deploy:
            steps:
            - template: YAMLTemplates\ProvisionUsingARM.yml
              parameters:
                AzureResourceGroup: $(AzureResourceGroup)
                AzureServiceConnection: PROD

But that is not at all what we are after, but it did at least show that it was possible to pass in the service connection name as a string parameter.

Using a global variable

If I declared a global pipeline variable, at the top of the pipeline file, it could be validated and queued without any issues.

variables:
  AzureServiceConnection: PROD

stages:
   ....

But again this was still not what I was after.

The Solution

In my project I have a number of variable groups, one for each stage of deployment. What I found I needed to do was to declare one of them as a global variable for the whole pipeline. This would allow the pipeline to be validated and queued without any issues, but in at each deployment stage this initial value is overridden by the variable group associated with the stage.

This does rely on the fact that the variable groups for each stage contain the same variable names.

The revised YAML looks as follows

# the build pipeline
variables:
# we have to globally declare this variable group, though it is override at the deployment job level
# if we don't do this the $(AzureServiceConnection) variable used by the Azure Resource deployment fails queue time validation 
- group: UAT

stages:
  - stage: UAT
    jobs:
    - deployment: ARM_Provisioning
      timeoutInMinutes: 0
      environment: 'Staging'
      variables:
      - group: UAT
      pool:
        vmImage: 'windows-latest'
      strategy:
        runOnce:
          deploy:
            steps:
            - template: YAMLTemplates\ProvisionUsingARM.yml
              parameters:
                AzureResourceGroup: $(AzureResourceGroup)
                AzureServiceConnection: $(AzureServiceConnection)
  - stage: PROD
    jobs:
    - deployment: ARM_Provisioning
      timeoutInMinutes: 0
      environment: 'Staging'
      variables:
      - group: PROD
      pool:
        vmImage: 'windows-latest'
      strategy:
        runOnce:
          deploy:
            steps:
            - template: YAMLTemplates\ProvisionUsingARM.yml
              parameters:
                AzureResourceGroup: $(AzureResourceGroup)
                AzureServiceConnection: $(AzureServiceConnection)

So I think a valid workaround for another strange YAML variable expansion issue in Azure DevOps.

The reason I find this so useful is that it allows me to make a series of small related changes to a project without having to clone the repository or using a CodeSpace, very useful when editing the related YAML files of reusable workflows in GitHub Actions.

I was recently working on a templated YAML Azure DevOps Pipeline project and pressed . our of habit and was really pleased to find that this VS Code in the browser feature is also available for Azure DevOps.

So next time you need to make a series of small changes to a project in Azure DevOps why not give it a try.

This is is one of those posts I write so I remember how to do something in the future.

Background

I recently had a need to generate many Visual Studio SQL Database Projects from existing databases. Being a good ’lazy developer’ I wanted to do this from the command line so I could automate the process, but it took me far to long to work out how

The Manual Way

If you only have one database to import you can do this manually by using the Import option in Visual Studio for an individual SQL Database Project.

1. Open Visual Studio
2. Create a new project using the SQL Server -> SQL Server Database Project template
3. Right click on the project in the Solution Explorer and select Import -> Database and follow the wizard.

The Command Line Way

For some reason I really struggled to find the command line syntax to perform the same action, so I am documenting it here for future reference.

The key command is SqlPackage.exe and the syntax needed will be something similar to

sqlpackage /Action:Extract /SourceConnectionString:"Server=tcp:{instance},{port};Initial Catalog={databasename};TrustServerCertificate=True;integrated security=true;" /TargetFile:{projectname} /p:ExtractTarget=SchemaObjectType

This command will generate an database project in a folder of the name specified using /TargetFile, where each SQL object has it’s own file containing the appropriate SQL CREATE script.

The ‘magic’ that took me too long to fine was that the /p:ExtractTarget=SchemaObjectType parameter is required. This instructs SQLpackage to generate a project structure and not extract to a single SQL file or DACPAC.

I am not sure whether my internet search powers were weak, or if this usage is just poorly documented, but I hope this post save future me, and others, some time.

However, today I was surprised to find I was getting cache misses on my pipeline, even though I was sure the cache should have been hit.

There are rules over how the cache is used:

• The cache is specific to a pipeline definition, so there is no sharing of the cache between pipeline definitions
• The cache is only created if the pipeline is successful (running the post run tasks)
• The cache only lasts 7 days
• but what I had not realised was the cache is also specific to the branch in a not so obvious way.

My pipeline was triggered off a PR, so the cache was being created on the ‘branch’ PR #123. This was working as expected, all runs of the PR triggered build used the cache after the initial run. However, if I manually triggered pipeline run of the same branch as the PR was using, there was a cache miss.

As far as the Azure DevOps cache task is concerned, the branch used for PR #123 and a manual run off the underlying branch used in the PR are different things, so the cache created by the PR was not being used by the manual branch build.

That explains a few slow builds I have had.

Programmatic connection to Azure DevOps cannot be done with your Active Directory credentials. This is because this involves a dialog being shown, and these days usually an MFA check too.

Historically, the solution to this problem was to enable Alternate Credentials, which could be passed as username and password, without the dialog being shown. However, the use of these has been deprecated since 2020, and they have been completely removed since Jan 2024.

So for a number of years the recommended way to programmatically authenticate with Azure DevOps has been to use a Personal Access Token (PAT). However, PATs are not without their own issues.

The problem with PATs

The most critical problem is that PATs expire. By default they expire after 30 days, and the longest you can set them to expire after is a maximum of 1 year. This means that you have to remember to renew them, and if you forget then your automation that rely on them will stop working.

Obviously it is very tempting to just set the expiry to 1 year, but this is not the best idea. The longer the expiry the more time there is for the PAT to be compromised. Just like SSL certificates, or any access token, the shorter period before the expiry the better.

Of course like any authentication and permission model you can grant too many permissions to a PAT, and then if it is compromised you have a problem, but that is on you not following the principle of least privilege, not a fundamental issue of PATs.

But what is the alternative?

Azure DevOps now offers support for Managed Identity & Service Principals. These are a much better way to provide a means to programmatically authenticate. Critically, they do not expire, and the tokens they generate for the actual connections are short lived, and you can of course grant them privileges in line with the principle of least privilege.

When used to access Azure DevOps resource, the only downside is they consume a basic user license.

This form of authentication is perfect for use in automation from locations like Azure Functions, or from the Az CLI.

What about GitHub?

The issue of PATs is not just one for Azure DevOps, the same problems are true for GitHub. On GitHub the solution is to use a GitHub App to authenticate with the GitHub API, and then use the short term token it can generate to authenticate with the GitHub API.

What about other outgoing services from Azure DevOps?

Another place you will see a move away from expiring secrets in Azure DevOps are Service Connections to services to such as Azure. You can now use Workload Identity Federation to authenticate with Azure.

Converting to use Workload Identity Federation is simple, you just press a button in the Azure DevOps UI, and it will create a Service Principal in Azure AD, and then update the Service Connection to use this to authenticate with Azure.

Once this is done there will be no need to remember to renew the Service Connection, as it will use the Service Principal to authenticate, and this does not expire.

Summary

So, when using Azure DevOps in many cases you can now avoid the use of PATs, and hence the need to remember to renew them. Giving you one less thing to remember to do, and one less thing to go wrong.

Since reading this I have made much more of an effort to keep my Azure DevOps Extensions up to date. Dependabot generated PRs have been a great help in this regard. Creating PRs for vulnerabilities and out of date dependencies.

However, no level of AI can protect you from stupidity. Recently, as part of addressing a vulnerability via a refactoring to change testing framework, I wasted far too long trying to work out why all my test passed in my Codespace, but failed in the CI build. I had forgotten to commit the jest.config.js file as my .gitignorewas set to ignore all .JS files as I was working in TypeScript.

Very frustration, but a good reminder to always check the files you are committing are the ones you expect.

We saw an issue with our SonarQube 10.3 Developer Edition (that is running as a Docker image hosted in Azure) when it was doing the analysis of a project that included Azure Bicep files.

The Azure DevOps pipeline that triggered the SonarQube analysis was not failing, but within the SonarQube analysis step an error was reported in the task log

INFO: Sensor IaC AzureResourceManager Sensor is restricted to changed files only
INFO: 1 source file to be analyzed
##[error]ERROR: Cannot parse 'AzureServices/QueryPack.bicep:89:1'

The Solution

Turns out the problem was related to parsing Bicep files for App Insights Query packs.

If the Bicep resource for the query contains a body property that starts with a comment e.g.

resource querypacks_DefaultQueryPack 'microsoft.operationalInsights/querypacks/queries@2019-09-01-preview' = {
  parent: QueryPack
  name: ...
  properties: {
    displayName: ...
    description: ..
    body: '// 35 is ABC\r\n// 40 is XYZ \r\nrequests\r\n| where name has "myfacade.svc"\r\n| order by timestamp desc\r\n| where name !has "GET"\r\n| summarize count() by name, resultCode\r\n| render columnchart'

We get the error ##[error]ERROR: Cannot parse 'AzureServices/QueryPack.bicep:89:1

We can fix this by not starting the body with a comment, just moving the comment to the end of the body i.e.

resource querypacks_DefaultQueryPack 'microsoft.operationalInsights/querypacks/queries@2019-09-01-preview' = {
  parent: QueryPack
  name: ...
  properties: {
    displayName: ...
    description: ..
    body: 'requests\r\n| where name has "myfacade.svc"\r\n| order by timestamp desc\r\n| where name !has "GET"\r\n| summarize count() by name, resultCode\r\n| render columnchart\r\n// 35 is ABC\r\n// 40 is XYZ'

This site was built using Hugo, a static site generator. I recently tried to do a long overdue update the version of Hugo from 0.108 to the current 0.122 version.

I had not expected any problems, but found that the site failed to render, but with no error message all I saw was

hugo.exe server --logLevel info
Start building sites …
hugo v0.122.0-b9a03bd59d5f71a529acb3e33f995e0ef332b3aa+extended windows/amd64 BuildDate=2024-01-26T15:54:24Z VendorInfo=gohugoio

INFO  copy static: syncing static files to \
INFO  build: running step "process" duration "97.3263ms"
INFO  build: running step "assemble" duration "335.1476ms"

I normally would have expected to see a INFO build: running step "render" line or an error, but got nothing, irrespective of the log level I set.

The Solution

As I had no error message, and found nothing of use in the Hugo resources, I decide my only option was to roll back to a previous version of Hugo until I could get the site to render.

So I downloaded various versions and in the end found that this site rendered on 0.116 but not 0.117.

At this point I knew that some check being done in 0.117 was the issue, and this had to be due to my page content.

So the next step was to use a bisect test pattern to find the problem pages i.e. delete half the pages, if the problem does not occur you know the problem exists in the other half, if it is still present it is in the half you deleted.

By repeating this process I was able to find the problem pages. The issue turned out to be remotely hosted images that could not be found referenced in older blog posts. It seem that the Hugo render now checks for the existence of images in the content, and if they are missing the site fails to render.

Anyway after editing the pages to remove the missing image markdown the site rendered correctly in 0.117 and 0.122.

It is just a shame the logging was not more helpful.

The flow created without issue, and all the drop downs were correctly populated with O365 and Azure DevOps values as expected.

However, when the flow ran, on receiving an email to the correct inbox, it failed with a BadGateway error.

The problem turned out to be that the Work Item type I had set the flow to create was not available in the project I was trying to create it in (it was disabled in the process template).

So, if you get a BadGateway (502) error in Power Automated Flow, do not assume Azure DevOps is down, but rather you have a bad/invalid payload in the call being made to the Azure DevOps API. I think what is happening is the Azure DevOps API is returning a 4xx bad data error (which may have a bit more detail, but I doubt it from my past REST API experience), but you cannot see it as Power Automate is hiding that error with its own 502 BadGateway error.

So the tip is check the details of your payload and ensure it is valid for the API you are calling.

We run our SonarQube instance in a Docker container hosted in an Azure Web App Service. Today, with no notice, it failed. We did the obvious, just tried to restart it and the startup process failed.

Looking at the Azure Web App’s Log Stream we could see the following error repeated on each restart attempt

2023-09-27T15:30:00.797Z INFO - Starting multi-container app..
2023-09-27T15:30:01.024Z INFO - Pulling image: sonarqube:10.1-developer
2023-09-27T15:30:02.100Z INFO - 10.1-developer Pulling from library/sonarqube
2023-09-27T15:30:02.291Z INFO - Digest: sha256:45e7cf02e037b00028d20556a91111f8ae8ae2b2803e516cb0665dd605a6d8b2
2023-09-27T15:30:02.292Z INFO - Status: Image is up to date for sonarqube:10.1-developer
2023-09-27T15:30:02.326Z INFO - Pull Image successful, Time taken: 0 Minutes and 1 Seconds
2023-09-27T15:30:02.344Z INFO - Starting container for site
2023-09-27T15:30:02.346Z INFO - docker run -d -p 8289:9000 --name bmsonarqubeprodwebsite_sonarqube_0_ec31111b -e WEBSITES_ENABLE_APP_SERVICE_STORAGE=false -e WEBSITE_SITE_NAME=bmsonarqubeprodwebsite -e WEBSITE_AUTH_ENABLED=False -e WEBSITE_ROLE_INSTANCE_ID=0 -e WEBSITE_HOSTNAME=bmsonarqubeprodwebsite.azurewebsites.net -e WEBSITE_INSTANCE_ID=6d27706a6b4eb56feec6ef57ab9b360923c5761cabb3fb52eb6fc5f4cdfbace3 -e WEBSITE_USE_DIAGNOSTIC_SERVER=False sonarqube:10.1-developer -Dsonar.search.javaAdditionalOpts=-Dnode.store.allow_mmap=false
2023-09-27T15:30:02.347Z INFO - Logging is not enabled for this container.
Please use https://aka.ms/linux-diagnostics to enable logging to see container logs here.
2023-09-27T15:31:09 No new trace in the past 1 min(s).
2023-09-27T15:32:09 No new trace in the past 2 min(s).
2023-09-27T15:33:09 No new trace in the past 3 min(s).
2023-09-27T15:33:52.465Z ERROR - multi-container unit was not started successfully

The Solution

Something in the back of my mind, from when we ran an on-premises SonarQube instance, made me think of a corrupt ElasticSearch index.

Using Azure Cloud Storage Explorer, I connected to the sonarqube-data file share and deleted the ES8 data folder

I then restarted the container and it started OK, recreating the ES8 folder and re-indexing the SonarQube content.

Thus far all appears to be OK.

The other place I auto-generate social media posts is from releases via my project’s Azure DevOps Pipeline builds. These use a YAML Pipeline Template that calls a Marketplace task to post to Twitter and a PowerShell task to Invoke-WebRequest to post to Mastodon.

Recently the Twitter task started to fail, and given the recent changes to the Twitter API with the move to the V2 API, I decided a new solution was required.

I realised the simplest solution was to use another Azure Logic App sharing the connectors I had already created for my website posts. To make this change, my post build YAML template was greatly simplified to:

parameters:
- name: buildNumber
  type: string
- name: extensionName
  type: string
- name: socialmediaLogicAppURL
  type: string 

steps:  
# Update the build number variable so the next build will be the next minor version
- task: richardfennellBM.BM-VSTS-BuildUpdating-Tasks-DEV.BuildVariableTask-Task.BuildVariableTask@1
  displayName: 'Update Build Variable'
  inputs:
    variable: Minor
    mode: Autoincrement
    usedefaultcreds: false

# Get the PR title and hence the reason for the release
- task: richardfennellBM.BM-VSTS-ArtifactDescription-Tasks-DEV.ArtifactDescriptionTask.ArtifactDescriptionTask@1
  displayName: 'Get Git Artifact PR Reason'
  inputs:
    OutputText: 'OutputedText'

# Post to the Logic App to create various social media posts
- pwsh: |
   $msg = "I have just released Version ${{parameters.buildNumber}} of my Azure DevOps Pipeline ${{parameters.extensionName}} http://bit.ly/VSTS-RF $(OutputedText) "

   write-host "Posting message: $msg"
   $uri = "${{parameters.socialmediaLogicAppURL}}" 
   $body = "{ `"Message`": `"$msg`"}"
   
   Invoke-WebRequest -Uri $uri -Method POST -Body $body -Headers $headers -ContentType "application/json"
  displayName: 'Create social media posts about new release'

I can now just update the Logic App to change to which social media platforms posts are generated.

So, arguably a better solution as I am using each tool for the job it was designed for i.e handing off the orchestration of external systems to Logic Apps as opposed to managing it in the build pipeline.

When working with Azure DevOps, you may need to access the REST API if you wish to perform scripted tasks such as creating work items, or generating reports. Historically, you had to use a Personal Access Token (PAT) to do this.

If you look in my repo of useful Azure DevOps PowerShell scripts you will find all the scripts make use of a function that creates an authenticated WebClient object using a passed in PAT token.

function Get-WebClient {
    [CmdletBinding()]
    param
    (
        $pat
    )

    $webclient = new-object System.Net.WebClient
    $webclient.Encoding = [System.Text.Encoding]::UTF8
    $encodedPat = [System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes(":$pat"))
    $webclient.Headers.Add("Authorization", "Basic $encodedPat")
    return $webclient
}

which is used thus

$wc = Get-WebClient -pat "a-pat-string"
$result= $wc.DownloadString("https://dev.azure.com/MyOrg/MyProject/_apis/build/builds") | ConvertFrom-Json
$result.value

The problem with this approach is that the PAT tokens have to be managed. They expire after a period of time, so have to be regenerated and also, as they are in effect passwords, need to be stored securely.

A better approach

A newly available and better approach is to use an Azure AD App Service Principle to authenticate to Azure DevOps. This addresses the issues with PAT tokens, as the App Service Principles do not expire and are defined securely in Azure AD.

The basic setup is as follows

1. Create a new Azure AD App
2. Add the new App Service Principle to the Azure DevOps organisation as a user
3. Grant the App Service Principle the required permissions in Azure DevOps
4. Use the App Service Principle for programmatic authenticate to Azure DevOps e.g to the API

The sample script hence becomes

function Get-WebClient {
    [CmdletBinding()]
    param
    (
        $ClientID ,
        $Secret   ,
        $TenantID 
    )

    # This is a static value
    $AdoAppClientID = "499b84ac-1321-427f-aa17-267ca6975798/.default";

    $loginUrl = "https://login.microsoftonline.com/$tenantId/oauth2/token"
    $body = @{
        grant_type    = "client_credentials"
        client_id     = $ClientID
        client_secret = $Secret 
        resource      = $AdoAppClientID
    }
    $token = Invoke-RestMethod -Uri $loginUrl -Method POST -Body $body

    
    $webclient = new-object System.Net.WebClient
    $webclient.Encoding = [System.Text.Encoding]::UTF8
    $webclient.Headers.Add("Authorization", "Bearer $($token.access_token)")
    return $webclient
}

$wc = Get-WebClient -ClientID "a string" -Secret "a secret" -TenantID "a tenant id"
$result= $wc.DownloadString("https://dev.azure.com/MyOrg/MyProject/_apis/build/builds") | ConvertFrom-Json
$result.value

Now, the observant amongst you will have noticed in this sample the Get-WebClient function still takes a secret, which is less than optimal. So, in most use-case it is recommended that the token is retrieved using a certificate, rather than a secret, but the process is basically the same. See the worked Microsoft example for details.

The one potential downside of this approach is that the App Service Principle may require a paid for Azure DevOps license, but this is not always the case, it depends on the API calls you will be making.

Broadly speaking, calls to get Work Item details can be done with free stakeholder licenses, but others to get build or code details will probably require a basic license. However, remember you do get 5 free basic licenses, so there is a good chance you have one spare, or at worst they are only $6 a month.

So is this something that may make your programmatic access to Azure DevOps easier and more secure?

We use Lability to build Windows Server images for our test labs. Lability makes use of Desired State Configuration (DSC) to build the VM images. Part of this process is for Lability to download DSC modules, as ZIP files, from a NuGet feed such as PowerShell Gallery to inject into the created VM image.

Historically, we have stored our own private DSC modules on an internally hosted NuGet server. However, we wanted to move these modules to a private Azure DevOps Artifacts feed. The problem was that Lability does not support downloading of DSC modules from Azure DevOps Artifact feeds, whether they are public or private, because of the way the package URLs are constructed.

I am in the process of creating a PR for Lability to add support for Azure DevOps Artifact feeds, but I thought it worth this quick blog post on package URL formats as it might be useful to others.

URLs for PowerShell Gallery

The URL format for downloading a package from the PowerShell Gallery is well known, being

https://www.powershellgallery.com/packages/<package name>/<version>

Enter this URL in a browser and the requested package will be downloaded

URLs for Azure DevOps Artifacts

You might well expect the format for downloading a package from Azure DevOps Artifacts to be

https://pkgs.dev.azure.com/<AzDo Org>/_packaging/<Feed Name>/nuget/v2/Packages/<package name>/<version>

but it is not.

Stackoverflow suggests the URL format is

https://pkgs.dev.azure.com/<AzDo Org>/_packaging/<Feed Name>/nuget/v2/Packages(id=<Package name>,version=<version>)

However, this does not download a package, but rather an XML manifest file. But from this manifest we can see a <content> element that contains the URL to the package, and it is an interesting format.

So for the manifest URL

https://pkgs.dev.azure.com/myorg/_packaging/myfeed/nuget/v2/Packages(id=xNetworking,version=5.7.0.0)

the content URL is

https://pkgs.dev.azure.com/myorg/_packaging/myfeed/nuget/v2?id=xnetworking&version=5.7.0

Note that

• the package name is lower case
• the four part version number is replaced with a three part version number
• the XML encoded & value in the manifest is replaced with a simple &

The following gist is a function to build the required URL from the package name and version number and download the package as a ZIP file

Hope this helps someone and saves them some time.

Yesterday I released an updated version of my ReleaseNotes task that introduced a bug if the pipeline produced no artifacts. I am pleased to say I have fixed the bug, and addressed this gap in my test coverage.

However, this did mean for about 12 hours if you are using this task in a pipeline that did not produce artifacts, maybe one that just deployed consumed artifacts from other pipelines, you had a failing pipeline.

In this case all is not lost, as there is a feature of YAML pipelines I only recently discovered.

I knew you could select a specific major version of a task (as you can with Classic Builds and Releases) e.g.

- task: XplatGenerateReleaseNotes@3

or

- task: XplatGenerateReleaseNotes@4

However, did you know you can also pin a specific version of a task e.g.

- task: XplatGenerateReleaseNotes@4.6.2

Thus allowing you to pick any version you wish, and not just the major version. A great way to lock down your pipelines to a known good version of a task, whether as a short term fix or a long term audit control.

At Black Marble we have our own private build agents, but they are built using the same Packer process as the Microsoft hosted ones. I recently rebuilt our agents to match the latest version of the hosted agents, and I ran into an issue with some .NET 3.1 based x86 MSTests. The tests were failing with the following error:

A total of 34 test files matched the specified pattern.
##[error]Testhost process exited with error: A fatal error occurred. The required library hostfxr.dll could not be found.
##[error]If this is a self-contained application, that library should exist in [E:\Agent\_work\1\s\src\Ux.Common.UnitTests\bin\x86\Release\netcoreapp3.1\].
##[error]If this is a framework-dependent application, install the runtime in the global location [C:\Program Files (x86)\dotnet] or use the DOTNET_ROOT(x86) environment variable to specify the runtime location or register the runtime location in [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation].

When I checked the folder C:\Program Files (x86)\dotnet it was not there, .NET 3.1 x86 was no longer present on the agent.

This removal of the x86 .NET SDK from the Packer build appears to have occurred around the start of the year. As when I last rebuild out agents in December 2022, they still got the x86 .NET SDK installed.

Solution

I found the solution in this GitHub issue, to use an Azure DevOps task to install the .NET 3.1 x86 SDK as part of my build pipeline

    - task: UseDotNet@2
      displayName: Install .NET 3.1 x86 to support vstest.console.exe
      inputs:
        packageType: sdk
        version: 3.x
      env:
        PROCESSOR_ARCHITECTURE: x86

However, I found that it was not enough to just install the x86 SDK in this manner.

The UseDotNet@2 task installs the SDK into C:\hostedtoolcache\windows\dotnet and set the environment variable DOTNET_ROOT to point this folder, so the SDK can be found by tools that need it.

The problem is that vstest.console.exe does not seem to be aware of this environment variable, and even if DOTNET_ROOT is set it still looks in the default C:\Program Files (x86)\dotnet folder.

So I also needed to add the following PowerShell inline script to my build pipeline to also set the DOTNET_ROOT(x86) environment variable. This extra step was also detailed towards the start of the same GitHub issue when discussing manual install based workarounds, but I had initially missed it:

    - powershell: |
        # Set the DOTNET_ROOT(x86) so vstest.console.exe can find the SDK
        # The UseDotNet@2 only sets the platform independant DOTNET_ROOT one that is not read by vstest.console.exe
        Write-Host "Setting environment variable DOTNET_ROOT(x86)=$(Agent.ToolsDirectory)\dotnet"
        Write-Host "##vso[task.setvariable variable=DOTNET_ROOT(x86)]$(Agent.ToolsDirectory)\dotnet"
      displayName: 'Set `DOTNET_ROOT(x86)` environment variable'
   

So together these two steps allowed my x86 MSTest tests to run successfully again.

I was recently trying to use PowerShelGet Install-Package to install a module from an Azure DevOps Artifacts hosted PowerShell Gallery using the following script

# For authentication use a PAT as the password, UID can be anything
$PATcreds = Get-Credential 
Register-PSRepository -Name BM -SourceLocation 'https://pkgs.dev.azure.com/<org>/_packaging/PowerShell/nuget/v2' -PublishLocation 'https://pkgs.dev.azure.com/<org>/_packaging/PowerShell/nuget/v2' -InstallationPolicy Trusted
Install-Package BlackMarble.Package -Source BM -Credential $PATcreds

The script did not work I was getting the error

Install-Package : Cannot find the path ‘C:\Users<user>\AppData\Local\Temp\936930114\BlackMarble.Package\BlackMarble.Package.0.3.79\BlackMarble.Package.psd1’ because it does not exist.

You could see a download progress bar that suggested the download had occurred, but no module was installed.

Solution

Turns out the answer was to not register the repository, but to use a URL in the -Source parameter to Install-Package.

Install-Package BlackMarble.Package  -Source https://pkgs.dev.azure.com/<org>/_packaging/PowerShell/nuget/v2 -Credential $PATcreds

It sort of makes sense that there could be a bug such that URLs work and aliases, added via a register-psrepository, do not. Maybe a bug?

However, more strangely I have found that if the alias is registered the the Install-Package fails even if a URL is used. The complete solution is therefore to first unregister-psrepository the alias that match the URL you wish to use before running the Install-Package command.

All very strange

It is a really useful feature that you can expose Key Vault stored secrets as Azure DevOps pipeline variables via a variable group, but what happens when you do this? And what can you do if you try to expose too many variables?

I was recently working on a system where there was an increasing number of Key Vault secrets that were being exposed as variables via a variable group. This was working fine, until I started getting warnings in the following form on Windows based Azure DevOps agents:

Environment variable ‘VSTS_SECRET_VARIABLES’ exceeds the maximum supported length. Environment variable length: 32993 , Maximum supported length: 32766

It was flagged as a warning, but in reality the pipeline failed as none of the secrets were being exposed as variables.

Analysis

When you link a variable group to a Key Vault, the secrets are exposed as environment variables. This is automatically done by the pipeline agent running the AzureKeyVault@1 task (interestingly not the newer AzureKeyVault@2 task) prior to any other steps in the containing job. This task takes parameters for the Key Vault name and a comma separated list based filter for the secrets to expose. Both of these are derived from the settings of the variable group.

Workarounds

The simplest workarounds are to either:

• Switch to a Linux based agent which has a much higher limit on the length of environment variables. A move that is not always possible depending on the other tasks in the job.
• Or to reduce the number of secrets exposed as variables. This can be done by either removing secrets from the Key Vault or by removing secret mapping within the variable group. A valid solution, but one that requires manual management.

This got me thinking, is there another way to build the secret filter list so it is more flexible than a manually managed comma separated list?

The answer is yes, you can use a PowerShell script to build the list of secrets to expose and then call the AzureKeyVault task directly.

Instead of exposing the key Vault secrets via the variable group, you could use the following tasks.

• A PowerShell script is used to convert a wildcard based filter into a comma separated list of secrets(this does assume you have a consistent secret naming convention)
• Then, use the same AzureKeyVault task, to expose the secrets as environment variables.

I am using an Azure Function as backend for processing forms submissions from a Hugo static website, to process a simple contact form.

I wanted to add reCAPTCHA support, as the site was generating too many spam emails. I also wanted to show a different confirmation pages depending on whether the reCAPTCHA check passed or failed

There a good few posts about using an Azure Function as backend for a static web site form. But what I could not find was how to handle the return value from the Azure Function.

So as I have a solution, I thought a blog post would be a good idea to share it.

The solution

On my contact form Hugo layout page, I have a hidden iframe, this is used as the target for the HTML form i.e. where the Azure Function posts back too. The Azure function returns a simple string, either “OK” or an error message depending on the outcome of the processing. The hidden target iframe has an onload event handler that checks the return value and redirects the user to a different page depending on the outcome.

<script type="text/javascript">var submitted = false;</script>

<iframe name="hidden_iframe" id="hidden_iframe" style="display:none;" onload="
    if(submitted) {
        const res = document.getElementById( 'hidden_iframe' ).contentWindow.document.body.innerText +']';
        if (res.includes('OK')) {
          window.location='/confirmation/enquiry';
        } else {
          window.location='/confirmation/error';
        }
    }
    ">
</iframe>

<form name="contact" action="/api/GenericFormsHandler" method="POST" target="hidden_iframe" onsubmit="submitted=true;">

    <input id="g-recaptcha-response" name="g-recaptcha-response" type="hidden" value="" />
    <script src="https://www.google.com/recaptcha/api.js?render={{.Site.Data.reCAPCHA.key}}&hl=en"  ></script>
    <script>
        if (typeof grecaptcha !== 'undefined') {
            grecaptcha.ready(function () {
                grecaptcha.execute('{{.Site.Data.reCAPCHA.key}}', { 'action': 'submit' }).then(function (token) {
                    document.getElementById('g-recaptcha-response').value = token;
                });
            });
        }
    </script>
    <!-- all my input fields -->
    <input type="submit" id="submitButton" value="Submit" />
</form>

My Azure Static WebSite is configured to contain a managed Azure Function with an HTTP trigger ‘/api/GenericFormsHandler’ to handle the forms processing.

import { AzureFunction, Context, HttpRequest } from "@azure/functions"
import fetch from "node-fetch"; // needs to be installed with npm i node-fetch@2.6.1 

const httpTrigger: AzureFunction = async function (context: Context, req: HttpRequest): Promise<void> {
    context.log('An HTTP POST trigger function to processed enquiry forms');
    var object = {};
    var returnValue = "OK";
    object["events"] = [];
    var status = 200;

    // a very basic HTML form to object parser
    req.body.split('&').forEach(field => {
        var pair = field.split("=")
        object[pair[0]] = decodeURIComponent(pair[1]).replace(/\+/g, " ")
    }

    context.log("Validating recaptcha token");
    
    // the secret key is stored in the Azure Function App settings
    var postData = `secret=${process.env.RECAPTCHA_SECRETKEY}&response=${object["g-recaptcha-response"]}`

    context.log(`reCAPTCHA request payload: ${JSON.stringify(postData)}`);

    // recaptcha validation only accepts POST requests using 'application/x-www-form-urlencoded' content type
    const response = await fetch("https://www.google.com/recaptcha/api/siteverify", {
        method: 'POST',
        body: postData,
        headers: {
            'Content-Type': 'application/x-www-form-urlencoded',
            'Content-Length': `${JSON.stringify(postData).length}`
        }
    });

    if (!response.ok) {
        context.log("Error calling reCAPTCHA");
        returnValue = "Error"
    }
    else if (response.status >= 400) {
        context.log('HTTP Error from to reCAPTCHA: ' + response.status + ' - ' + response.statusText);
        returnValue = "HTTPError"
    }
    else {
        context.log("Successful call to reCAPTCHA");
        const data = await response.json();
        context.log(`reCAPTCHA response: ${JSON.stringify(data)}`);

        // if the score is less than the minimum score (App settings) then we don't process the form
        if (data.success && data.score >= parseFloat(process.env.RECAPTCHA_MINSCORE)) {
            context.log("Sending email as reCAPTCHA detected a human");
        
            const sgMail = require('@sendgrid/mail')
            sgMail.setApiKey(process.env.SENDGRID_API_KEY)
            const msg = {
                // App Settings use for the from and to addresses
                to: process.env.ENQUIRY_TOADDRESS, 
                from: process.env.ENQUIRY_FROMADDRESS, 
                html: // add in the content generate from th form content
            }

            await sgMail
                .send(msg)
                .then((response) => {
                    context.log(`Send Email returned  ${response[0].statusCode}`)
                    context.log(response[0].headers)
                    returnValue = "OK"
                })
                .catch((error) => {
                    context.log(`ERROR sending email ${error}`)
                    returnValue = error;
                })
		
		} else {
           context.log("Not sending email as reCAPTCHA detected a bot");
            returnValue = "reCAPTCHA Error"
        }
    }

    context.log(`Setting return value as ${returnValue}`);
    context.res = {
        body: returnValue
    };
};

export default httpTrigger;

Important

The key thing to note with this solution is that you get the Azure Function to write it’s return value into the hidden iFrame on the calling page.

The only reason that this iFrame content (the return value) can read (using JavaScript on the form page) is because the Hugo static pages and managed Azure Function are in the same domain. So there are no cross site scripting issues blocking the reading of the iFrame contents e.g. your get no console error messages in the form:

SecurityError: Blocked a frame with origin “http://www.example.com” from accessing a cross-origin frame.

Hence, the logic on the onload function can pick the correct confirmation page based on the value returned by the Azure Function.

Conclusion

So, not the most elegant solution, but it works.

Hope this post save some other people some time

After deploying a dotnet 6 console app to a production server, I got the following error:

Exception: [Could not load file or assembly ‘System.Data.Odbc, Version=6.0.0.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51’. The system cannot find the file specified.]

The strange thing was the same EXE, built on a Microsoft hosted Azure DevOps build agent, was working on the test server and was deployed using the same Azure DevOps Pipeline to both systems.

I tried many things to work out what the problem was. My first though was Fuslogvw, but found out I should be using dotnet-trace, but this showed nothing other than the assembly was not found i.e. no downstream dependencies were missing.

I then manually pulled the same deployment ZIP onto the server, unpacked it and ran the EXE from the command line, it worked - what was the difference?

Solution

Eventually I spotted the problem, the runtimes folder was missing on the copy that was deployed via the pipeline.

My automated deployment look like this

But my manual deploy had a runtimes folder with the platform specific folders in the runtimes folder

Remember, the same deployment pipeline was deploying the same artifact to both the test and production servers, and I could see the folder structure was correct in the build agent staging folder (where the ZIp was expanded prior to the copy). So why the differences?

And it got stranger, I redeployed the package using the same pipelines (just a re-run stage, not a complete now run) and this time the runtimes folder was there, and the EXE worked!

Conclusion

I am just going to put this one down to a glitch in the matrix, maybe related to debris in the target folder?

But the learning is, when you get missing assembly errors with a .NET 6 (or .NET Core) deployment make sure the runtime folder is present and contains the platform specific folders.

Also make sure your target folder is empty before copying in the new code to avoid any debris from previous deployments just to be on the safe side.

I recently did our regular update of our Azure DevOps Private build agents. It is rare we see problems when we do this, but this time one of our very regularly run builds started to fail when running unit tests.

We had not changed the project source code, all the test ran locally in Visual Studio. We had not change the build pipeline YAML

  - task: VSTest@2
        displayName: 'Unit Tests - Services'
        inputs:
          testAssemblyVer2: |
            **\*.unittests.dll
            !**\obj\**
          searchFolder: '$(System.DefaultWorkingDirectory)/src

And from the pipeline logs, we could see that the CLI command being generated by the VSTest@2 task was also unchanged, finding 39 DLLs that matched the filter.

So the only change was the version of the Visual Studio tools installed on the build agent. Specifically vstest.console.exe had been updated from Version 17.3.2 (x64) to Version 17.4.1 (x64)

Solution

On checking the list of DLLs containing tests to be run we saw that some unit test DLLs were duplicated. They were appearing in their expected folders, but also in other project folders e.g.

vstest.console.exe “E:\Agent_work\3\s\src\BM.Services\BM.Service1.UnitTests\bin\Release\BM.Service1.UnitTests.dll” “E:\Agent_work\3\s\src\BM.Services\BM.Service2.UnitTests\bin\Release\BM.Service2.UnitTests.dll” “E:\Agent_work\3\s\src\BM.Services\BM.Service2.UnitTests\bin\Release\BM.Service1.UnitTests.dll” …

This was due to reference entries in the .csproj files that should not have been there.

So, the fix was to just remove the incorrectly present references to the DLLs in the various .csproj files.

This is one of those problems that makes you ask ‘why has this not been an issue before?’, but at least it is fixed now.

I have blogged previously about moving various web sites over to become Hugo Static Sites.

Recently one of my site’s, one using the tailwindscss module, GitHub Build and Deployment Workflow started failing with the following error:

Start building sites … 
hugo v0.108.0-a0d64a46e36dd2f503bfd5ba1a5807b900df231d+extended linux/amd64 BuildDate=2022-12-06T13:37:56Z VendorInfo=gohugoio
Error: Error building site: POSTCSS: failed to transform "css/style.css" (text/css): node:internal/errors:478
    ErrorCaptureStackTrace(err);
    ^

SystemError [ERR_SYSTEM_ERROR]: A system error occurred: uv_os_homedir returned ENOENT (no such file or directory)
    at Object.<anonymous> (/opt/nodejs/16.18.0/lib/node_modules/npm/node_modules/clean-stack/index.js:6:61)
    at Module._compile (node:internal/modules/cjs/loader:1155:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1209:10)
    at Module.load (node:internal/modules/cjs/loader:1033:32)
    at Function.Module._load (node:internal/modules/cjs/loader:868:12)
    at Module.require (node:internal/modules/cjs/loader:1057:19)
    at require (node:internal/modules/cjs/helpers:103:18)
    at Object.<anonymous> (/opt/nodejs/16.18.0/lib/node_modules/npm/node_modules/aggregate-error/index.js:3:20)
    at Module._compile (node:internal/modules/cjs/loader:1155:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1209:10) {
  code: 'ERR_SYSTEM_ERROR',
  info: {
    errno: -2,
    code: 'ENOENT',
    message: 'no such file or directory',
    syscall: 'uv_os_homedir'
  },
  errno: [Getter/Setter],
  syscall: [Getter/Setter]
}
Total in 1653 ms

Solution

The problem it turned out was that the default version of Node used by the GitHub Actions runner had changed from Node 14 to Node 16.

I needed to explicitly set the version of Node to use in the workflow file to Node 14.

jobs:
  build_and_deploy_job:
    if: github.event_name == 'push' || (github.event_name == 'pull_request' && github.event.action != 'closed')
    runs-on: ubuntu-latest
    name: Build and Deploy Job
    env:
      HUGO_VERSION: 0.108.0
      NODE_VERSION: 14
    steps:
     ....

Once this was set the build worked as expected.

It is easy to create an Open Source Project and leave it to gather technical debt as the libraries it depends upon are updated.

I have tried to keep on top of updating all my Azure DevOps Pipeline Extensions, and I have to say Dependabot has certainly helped, but I have not been as diligent as I might have been.

So, as a Christmas project, I took the chance to start to do a major update of all my extensions. To make sure they used the newer Node16 execution runner (as per the document update process) and to update all the NPM packages used.

Steps (Part1)

• In each task.json file
  • Update the minimum runner version
  • Add the Node16 based runner (assuming the task is Node based as most of mine are, I do have one or two PowerShell based ones)
• Update all the NPM packages. I used npm-check-updates to do this.
• I then checked that task still built locally (the TypeScript linting and transpilation)
• I then ran my mocha/chai based test locally, and this is where I hit problems.

Problems with Mocha and TypeScript

The error I got was in the form

TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension “.ts” for D:\a\1\s\Extensions\WikiPDFExport\WikiPDFExportTask\test\foldercreation.test.ts

Seems this is a known issue. As suggested, I tried swapping from the "require": "ts-node/register" to "loader": "ts-node/esm" in the .mocharc.json file, this caused the error to changed to

mocha ./test/.test.ts (node:31412) ExperimentalWarning: Custom ESM Loaders is an experimental feature. This feature could change at any time (Use node --trace-warnings ... to show where the warning was created) Warning: Cannot find any files matching pattern “extensions/**/test/.ts”

TSError: ⨯ Unable to compile TypeScript: test/foldercreation.test.ts:12:23 - error TS2695: Left side of comma operator is unused and has no side effects. 12 var actual = (0, GitWikiFunctions_1.GetWorkingFolder)(".\", “testdata\subfolder\1\file.md”, agentSpecific_1.logInfo);

I battled with this for a while, but in the end gave up and just set my test macro to do the transpile first and then running mocha against the .js files, as opposed to letting mocha do all the steps itself.

So, swapping from

"test-no-logger": "mocha -r ts-node/register ./test/*.test.ts "

to

"transpile": "tsc -p ./",
"test-no-logger": "npm run transpile && mocha ./dist/test/*.test.js "

I could now run my tests locally, but some were failing. This turned out to be due to using the older del NPM module. I swapped to fs-extra and all was good.

Steps (Part2)

When it all builds and tests locally you can continue

• As this is a major change and to give people the choice as to whether to update, I updated the Major version and zero’d the Minor version numbers in the CI/CD pipeline that publishes the task (for my extensions I chose to manually manage the major versions, increment the minor version for each public release, and use the patch as build number)
• Create PR and let the CI/CD pipeline deploy a private version of the extension to the Azure DevOps Marketplace
• I can then increment the task version number in the pipeline YAML files so the new version is tested (you can’t set this until you have deployed the incremented extension to the marketplace as the YAML validation will fail)

And that should be it…

Summary

This all seems a lot of work, but is essential if my OSS extensions are to trustworthy and usable. I have a few more to do, but I am hoping to get them all done before the end of the year.

I am getting back out in front of audiences again as opposed to doing Teams/Zoom events. So I dug out my trusty Logitech Spotlight presentation remote from the bag where it had been sitting for well over a year. However, there was a problem, it would not pair with my re-built Windows 11 PC. It could not even switch on.

A quick search showed I was not alone in having this problem, the Logitech forums showed a lot of angry people. The summary was, if left alone for a few months a Spotlight goes so flat it cannot be charged, and Logitech don’t have a fix, or seem to care. There were a lot of comments about very expensive paper weights.

The Fix

The solution, found a in thread comment on the Logitech Forum, was this very useful video from 2ai.

The basic summary is to charge the battery via an external source to kick start the Spotlight. You can see a photo of the setup I used here.

A few comments on the process:

• Getting the back off the Spotlight remote is a pain, even using my iFixit tools I added a few scratches to the case.
• As the video said, the soldering is delicate, you need to strip a way the cellophane to expose the solder points.
• The video was not clear on the polarity or voltage of the battery/PSU.
  • The wire from the centre terminal on the Spotlight battery was connected to the +ve terminal on my PSU
  • The wire from the outside terminal on the Spotlight battery was connected to the -ve terminal on my PSU
  • I used a variable voltage power supply. I switched it on at its minimum of 3V and slowly increased the voltage until the Spotlight leapt into life at about 4V. This took only a few seconds.
• As soon as the Spotlight came to life, I plugged in a USB-C cable and removed my externally connected the PSU connections. Leaving the Spotlight to fully charge via USB.

So a slightly fiddly fix, but it worked. Much better than the alternative of buying a new remote and sending the old one to e-waste/landfill.

Updated 16 Nov 22 - I spoke to soon

It seems the fix was only temporary. The battery in the Spotlight is not holding charge, so I have a remote that works as long as I have it plugging in via a USB-C charging cable (or I suppose an external battery pack). So, not the most remote of remote presenter devices!

So I did more digging and found this battery replacement guide on iFixit. So, I have ordered a suitable battery and will update this post when it arrives and I have done the replacement.

Updated 19 Nov 22 - Success at last

I have fitted the replacement 90mAh 3.7V Lithium Polymer Li-Po li ion Rechargeable Battery and the Spotlight is now working as it should. I did have not had to charge it, via the USB-C cable, but once done the remote works as it should.

It will be interesting to see how long the battery lasts, but even if it has to be charged more often, it is still a lot better than having a dead remote.

So if you have this issue, I would recommend a battery swap. It is not that hard to do, and the battery is not expensive. Much better than a $150 paper weight.

Updated 27 Sept 2023 - I let it go flat again!

I left my Logitech Spotlight in my bag and it went flat again. So I was back to square one, it would not charge.

I first tried to ‘jump start it’ again, putting 4V from an external PSU across the battery terminals while it was also connected to USB power to charge the battery.

Initially it appeared to work, but as soon as I removed the external USB power it died again.

Next, I unsoldered the battery and tested it, it seemed OK giving around 4V.

So I reconnected it, plugged in USB power, this time overnight, then tested it again. This time it worked.

So either it was a poor battery connection, or the battery just needed a much longer charge as it was so flat.

I have used these tools before, but it was a while ago, and as it is under active development, I had to relearn a few things. It is fair to say that the learning curve for this tool is steep, but as the documentation does not hide this

WARNING: This tool is not designed for a novice. This tool was developed to support the scenarios below, and the edge cases that have been encountered by the 30+ contributors from around the Azure DevOps community. You should be comfortable with the TFS/Azure DevOps object model, as well as debugging code in Visual Studio

So where did I trip up this time?

But the documentation!

The documentation is OK, but can be confusing at the start as page links loop back on themselves. Adding to confusion is that there are details for older legacy V1 processors, current V1 processors and new V2 ones, but the reality is you are probably using only a small subset of the ones listed. Probably just current V1 ones for most use cases.

In my case I could ignore all bar the WorkItemMigrationConfigprocessor and the three ‘beta’ Test*MigrationConfig processors, and I suspect this is true for many people. This might not appear the case on a first read of the documentation.

Today, the WorkItemMigrationConfig processor is the one that does the bulk of the work, doing the work previously done by a set of legacy processors e.g creating Iteration and Area nodes.

Recreating Configuration Files

Always recreate your configuration file when you update the version of the migration tools you are using. The whole schema could have changed and some option settings certainly will have.

The documentation does tell you to do this, don’t be tempted to just update the version number in the config file, it usually does not work as you miss a required new setting. It is invariably quicker to re-add in your source and target details, rather than work out what other flag has changed.

Watch our for case sensitivity

I found that the current version, V12, is much more case sensitive than previous versions. I initially had my target Team Project name in lower case, and the tools failed in the strangest way.

A connection was successfully made to the team projects, but when it tried to create the missing iteration or area paths it failed with message about being unable to create nodes i.e.

NewNode is not anchored in the target project, it cannot be created

A search of GitHub Issues, GitHub Discussions and Stack overflow thread for this error suggested problem with the configuration values for the NodeBasePaths settings. However, after a bit of interactive debugging, I found this was not the root cause. In fact, as I was doing a simple copy migration all tht was needed was an empty array for the NodeBasePaths, as I had first thought.

The debugging showed that the problem was the case of the target project name. The mismatch meant a regex expression was failing to match the built in root Area and Iteration nodes. Hence the error.

So, top tip, copy and paste in URLs and Team Project names to avoid stupid typos

How to increase the chances of a successful migration

I always start by migrating over a single work item of a given type into a test target project. When this works, I try a single work item of another type. I repeat this process until I have migrated all the work item types in use.

I will try to selectively pick sample work items so there are relationships between them, thus ensuring the linking is working, and ones with attachments, to ensure those are migrated correctly too.

Once I know all the work item types can be migrated, then and only then do i try to run a migration for all the work items in the source project.

It is far better to spend a few minutes making sure all the work item type field and states are mapped correctly, rather than finding a few hours into a long migration run.

The way I do this filtering is to edit the WIQLQueryBit

"WIQLQueryBit": "AND  [Microsoft.VSTS.Common.ClosedDate] = '' AND [System.WorkItemType] NOT IN ('Test Suite', 'Test Plan','Shared Steps','Shared Parameter','Feedback Request') AND [System.Id] = '1234'",

Note: The configuration file does contain a "WorkItemIDs":[] setting that the documentation says is “A list of work items to import”. I had assumed this would filter the work items returned by the WIQL query, it does not. After looking at the code it does not seem to be used at present in the WorkItemMigrationConfig processor.

A key advantage of the WIQL approach is by filtering the number of work items returned to a single one, the migration tools will start much more quickly. There is a ’tax’ on every run of the migration tools where it has to do analysis of the source and target projects to work out what needs to be migrated. If it has to check hundreds or thousands of work items this will take many minutes. However, if it only has to check one, it will be done in, from my experience, around 10 seconds

Summary

Using this tool is always an adventure, but it does what it says it will when you have it configured correctly.

And if you do have problems, the debugging logs are detailed, and there is active support on GitHub Issues and GitHub Discussions.

If you do have problems, don’t be afraid of running the tool using Visual Studio. This is a great way to debug the flow and see what is going on. If you do make changes remember this is an open source project and your bug fix and enhancement PRs will always be considered.

The bottom line is that you just have to accept that this form of migration will be a slow process, but once you have the basics of the configuration file correct the tool is reliable.

I recently had a strange problem. I had an existing Azure DevOps YAML Pipeline that used the checkout task to do a deep Git fetch of a repo and it’s submodules. The reason for the deep fetch was that later in the pipeline we ran GitVersion and this needs the whole repo to be able to calculate the version.

- checkout: self
        persistCredentials: true
        submodules: true

- task: gitversion/setup@0
    displayName: 'Get current version of GitVersion'
    inputs:
    versionSpec: '5.x'

- task: gitversion/execute@0
    displayName: 'Run GitVersion to generate SEMVER'
    inputs:
    useConfigFile: true
    configFilePath: '$(System.DefaultWorkingDirectory)/GitVersion.yml'

On this original pipeline this was all working as expected.

However, when I created a second Azure DevOps pipeline that pointed to the same YAML file, expecting it to work without issues, it failed at the GitVersion task. It could not calculate the version.

On checking the pipeline logs, I could see that the git checkout had used a depth of 1 i.e. a shallow fetch, more efficient, but not providing all the branch and commit information GitVersion needs

The fix

It seems that on this 2nd pipeline the UX based pipeline settings were set differently, overriding the YAML ones, so causing a shallow fetch to be used.

When I switched off the UX ‘set shallow fetch’ all worked as expected [accessed via Pipeline > Edit > Ellipsis menu > Triggers > YAML tab]

Confusing that a cloned pipeline should end up with different settings, especially when the setting you need to change is far from easily discoverable

As I had no similar demo for GitHub Enterprise, I thought it would be interesting to see how the migration process taking my Azure DevOps implementation over to GitHub would go. This is a good learning exercise as it is the type of problem that many of our enterprise clients will need to do if changing DevOps platform. My key aim was to do the minimum to get the CI/CD process moved from Azure Pipelines to GitHub Action

Moving the source

This was easy, I just imported the Git repo from Azure DevOps

Build

The build for my solution was fairly easy, the project is a pair of Visual Studio solutions, one for the ARM code and the other for the Website code.

The key point was to make sure I passed in the correct parameters to make sure the web site was packaged up using WebDeploy

  Build-Solution:
    runs-on: windows-latest

    steps:
    - uses: actions/checkout@v3

    - name: Add MSBuild to PATH
      uses: microsoft/setup-msbuild@v1.0.2

    - name: Restore NuGet packages
      working-directory: ${{env.GITHUB_WORKSPACE}}
      run: nuget restore ${{env.SOLUTION_FILE_PATH}}

    - name: Build Solution
      working-directory: ${{env.GITHUB_WORKSPACE}}
      # Add additional options to the MSBuild command line here (like platform or verbosity level).
      # See https://docs.microsoft.com/visualstudio/msbuild/msbuild-command-line-reference
      run: msbuild /m /p:Configuration=${{env.BUILD_CONFIGURATION}} /p:DeployOnBuild=true /p:PublishProfile=${{env.BUILD_CONFIGURATION}} ${{env.SOLUTION_FILE_PATH}}

Deployment

The majority of the work was required to get the solution deployed i.e.

• Creating all the required Azure resources using an ARM template
• Deploying the website via MSDeploy.

In Azure DevOps I had tasks to manage these steps, for GitHub actions, though some actions exist, I also had to write some scripts.

I ended up putting the Actions required for the ARM and Solution deployment in reusable workflows, so I could call the steps at multiple locations on my workflows (for the test deployment and the production deployment) without repeating actions.

ARM

The workflow for the ARM was as follows. Nothing that special, the key points to note are

• You have to use the Azure Login action, this in effect replaces the Azure Pipelines service connection.
• I have to use a script to check the Azure resource group exists prior to the deployment. In Azure Pipelines the ARM task will create the resource group if not present, but this is not so with the GitHub Action
• I inject all my ARM parameters as inline parameters (as opposed to a file), this was just to keep the same pattern as had been used on Azure DevOps

name: Reuseable workflow to publish ARM to Azure resource group

on:
  workflow_call:
    inputs:
      environment:
        required: true
        type: string
    # all secrets inherited    
jobs:
  Integration-ARM:
    runs-on: windows-latest
    environment:
      name: ${{ inputs.environment }}
    steps:
    - name: Download ARM Build Artifact
      uses: actions/download-artifact@v3.0.1
      id: arm-download
      with:
        # Artifact name
        name: ARM
        path: ./ARM

    - name: Azure Login
      uses: Azure/login@v1.4.6
      with:
        creds: ${{ secrets.AZURE_CREDENTIALS }}     

    - name: Ensure Azure Resource Group is created
      run: |
        $rgexists = az group exists -n ${{ secrets.AzureResourceGroup}}
        if ($rgexists -eq 'false') {
          az group create --name ${{ secrets.AzureResourceGroup}} --location ${{ secrets.AZURELOCATION }}
          write-host "Creating Azure Resource Group"
        }
      shell: pwsh 

    - name: Deploy Azure Resource Manager (ARM) Template
      uses: Azure/arm-deploy@v1.0.8
      with:
        scope: 'resourcegroup'
        subscriptionId: ${{ secrets.AZURESUBSCRIPTION }}
        region: ${{ secrets.AZURELOCATION }}
        resourceGroupName: ${{ secrets.AzureResourceGroup}}
        template: '.\\ARM\\Templates\\WebSiteSQLDatabase.json' 
        deploymentMode: 'Incremental'
        parameters: 'hostingPlanName="${{ secrets.HostingPlanName}}" hostingPlanSku="${{ secrets.hostingPlanSku}}" hostingPlanCapacity="${{ secrets.hostingPlanCapacity}}" webSiteName="${{ secrets.Sitename}}" sqlserverName="${{ secrets.sqlservername}}" sqlServerAdminLogin="${{ secrets.SQLUser}}" sqlServerAdminPassword="${{ secrets.SQLPassword}}" databaseName="${{ secrets.databasename}}" collation="SQL_Latin1_General_CP1_CI_AS" edition="Standard" maxSizeBytes="1073741824" requestedServiceObjectiveName="S0" appInsightsLocation="${{ secrets.AzureLocation}}" VersionTag="1.2.3"" DeploymentDate="2022-10-28"" EnvironmentTag="tag"'

Solution

The MSDeploy was more problematic. It is fair to say this is not a currently fashionable technology. Web deploy has very much moved to the ‘copy a zip file’ approach. There was no GitHub Action available to run MSDeploy against Azure, so I had to work out the parameters and script it.

Again the key points to note

• I could not find a GitHub Action that would automatically update a configuration file replacing tokens found with values from environment variables and secrets. There a few that do part of the job, but not it all. This is something I might well write, but for now a script that replaces the tokens did the job - and yes I know it is probably better practice to set these values in the Azure WebApp directly, but as I said I was trying for a like for like replacement.
• The MSDeploy relies on pulling down the publish profile then calling the MSDeploy EXE which is present on the GitHub Agent. This took a while to get right, but once it was done, it is reliable

name: Reuseable workflow to publish web solution to Azure WebApp

on:
  workflow_call:
    inputs:
      environment:
        required: true
        type: string
    # all secrets inherited    
jobs:
  Integration-ARM:
    runs-on: windows-latest
    environment:
      name: ${{ inputs.environment }}
    steps:
    - name: Download Web Deploy Solution Build Artifact
      uses: actions/download-artifact@v3.0.1
      with:
        # Artifact name
        name: 'Webdeploy-Package'
        path: ./WebDeploy

    - name: Replace tokens in configuration file
      run: |
        $file = ".\WebDeploy\FabrikamFiber.Web.SetParameters.xml"
        $filecontent = Get-Content -Path $file
        $filecontent = $filecontent -replace "__Sitename__", "${{secrets.Sitename}}" 
        $filecontent = $filecontent -replace "__LOCATION__", "${{secrets.LOCATION}}" 
        $filecontent = $filecontent -replace "__GENERATETESTDATA__", "${{secrets.GENERATETESTDATA}}" 
        $filecontent = $filecontent -replace "__sqlservername__", "${{secrets.sqlservername}}" 
        $filecontent = $filecontent -replace "__databasename__", "${{secrets.databasename}}" 
        $filecontent = $filecontent -replace "__SQLUser__", "${{secrets.SQLUser}}" 
        $filecontent = $filecontent -replace "__SQLPassword__", "${{secrets.SQLPassword}}"
        $filecontent | Out-File $file
        cat $file          
      shell: pwsh

    - name: Azure Login
      uses: Azure/login@v1.4.6
      with:
        creds: ${{ secrets.AZURE_CREDENTIALS }}     

    - name: 'Deploy web site with MSDeploy'
      run: |
        $publishProfile = az webapp deployment list-publishing-profiles --resource-group ${{ secrets.AzureResourceGroup}} --name ${{ secrets.Sitename }} --query "[?publishMethod=='MSDeploy']" --subscription "${{ secrets.AZURESUBSCRIPTION}}" | convertfrom-json
        $shortPath = (New-Object -ComObject Scripting.FileSystemObject).GetFolder("./WebDeploy").ShortPath  
        & "C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe" -verb:sync -source:package="$shortpath\FabrikamFiber.Web.zip" -setParamFile:"$shortpath\FabrikamFiber.Web.SetParameters.xml" -dest:auto,ComputerName="https://$($publishProfile.msdeploySite).scm.azurewebsites.net/msdeploy.axd?site=$($publishProfile.msdeploySite)",UserName=$($publishProfile.userName),Password=$($publishProfile.userPWD),AuthType='Basic' -verbose -debug -disableLink:AppPoolExtension -disableLink:ContentExtension -disableLink:CertificateExtension
      shell: pwsh

Summary

So I now have the core of my ‘Living the Dream’ demo on GitHub, the is more of course I can do, but it is a good start and has been a good learning experience.

This form of activity is something I would recommend to anyone trying to get their had around the intricacies of GitHub, or any technology new to them. You always learn more I think when trying to do your own project as opposed to just following a lab.

In the recent past, I have seen confusion from our clients as to what is Microsoft’s recommended DevOps solution, given they have both Azure DevOps and GitHub.

It is true that Microsoft have said, and continue to say, that GitHub is the ’north star’ the long term destination for all users. However, that does not help clients today. Many of mine ask ‘but I am using Azure DevOps, but all Microsoft seem to talk about is GitHub, is Azure DevOps dead?’.

Well today’s announcements in the conference session ‘Accelerate innovation with the world’s most complete cloud developer platform’ and the blog post ‘Integrate security into your developer workflow with GitHub Advanced Security for Azure DevOps’ goes a long way to answering that question with a positive answer.

‘Cool features’ from GitHub Enterprise, specifically Code Advanced Security, are coming to Azure DevOps, along with other Azure DevOps specific investments. Thus greatly re-enforcing the ‘better together’ story for Azure DevOps and GitHub, and that Azure DevOps has a future.

These changes could be taken two ways, depending on your position

• You could argue it makes it much clearer for both existing Azure DevOps and GitHub users to see their road-map, with both products sharing a common set of share services
• Conversely you could argue it muddles the waters and slows the inevitable move to GitHub

I suspect which position you take is dependent as to whether you are an Azure DevOps or GitHub Enterprise user.

If this is an area of interest, I will be talking more about these changes at Black Marble’s next free webinar titled ‘Which is best for me… GitHub, Azure DevOps, or Better Together?’ on 26th October 2022.

However, I recently found a problem when starting to use SonarCloud in an older codebase. You cannot do SonarCloud analysis of a child branch before the main/trunk has been analysed.

This is most likely an issue because you are using Azure DevOps YAML Pipelines and must commit your revised pipeline, that triggers SonarCloud analysis, via a PR i.e. you cannot commit direct to main/trunk.

However, in my case I was using Azure DevOps Classic Builds and it was because the work I was doing was to move a codebase from an unsupported version of .NET to .NET 4.8. On the build agents available to me I had no means to build the old codebase, and I was not minded to provision agents just to do that job. So I looked for away to analyse the main/trunk branch to unblock my PR analysis.

Normally SonarCloud analysis is done as part of the automated build process, but there are CLI tools to manage it too. I decided to use these in the quickest dirtiest way I could think of

1. I cloned my legacy repo (you never use the code in the repo, but it is needed so SonarCloud can detect the branch. You could possibly use an empty git repo as an alternative)
2. I switched to the main branch and created a folder off the roo
3. In this folder I created a new dotnet console app
4. From the root of the repo I ran the SonarCloud dotnet CLI Scanner, passing in the details required to create a new SonarCloud project

dotnet sonarscanner begin /k:"AKEY" /o:"<my sonarcloud org name>" /d:sonar.login="<your access token>" /d:sonar.host.url="https://sonarcloud.io" /n:"Project Name"

5. I then built the dotnet project
6. Finally I completed the SonarCloud analysis

dotnet sonarscanner end /d:sonar.login="<your access token>"

This created an analysis of the main branch with the single dotnet program.cs file

It is then possible to do the analysis of the child branches, with all the real code. What code is detected as ’new code’ in this branch by SonarCloud will be dependant on your settings. So even though the code on this first PR branch will have never been seen by SonarCloud, it might not be detected as new due to the file’s last modified dates.

I realise I could have locally built the legacy code on my PC (removing steps 2 & 3, and replacing step 5 with an MSBuild), but that would have required installing legacy frameworks I did not wish to do.

So a dirty hack, but got me out of a hole, and once the PR was completed SonarCloud showed all the code metrics I would expect.

Updated: 3rd Oct 2022

Just for completeness, these are command lines to do a local MSBuild of an existing codebase using the CLI Scanner. A better options if you have a dev PC available to build the legacy code based but not suitable build agent (and don’t want to make your PC a temporary build agent)

1. Clone the legacy repo
2. From the root of the repo run the SonarCloud dotnet MSbuild CLI Scanner, passing in the details required to create a new SonarCloud project

sonarscanner.msbuild.exe begin /k:"AKEY" /o:"<my sonarcloud org name>" /d:sonar.login="<your access token>" /d:sonar.host.url="https://sonarcloud.io" /n:"Project Name"

5. Built the legacy project(s) with MSBuild

'C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\msbuild' .\MyProjectFolder\MyProject.csproj

6. Completed the SonarCloud analysis

sonarscanner.msbuild.exe end /d:sonar.login="<your access token>"

However, there is the option to ingest Generic Issue Data. To make use of this I just needed to change my XML results file to a JSON format

Once this was done the only remaining step was to tell SonarCloud where the coverted JSON file was

# Additional properties that will be passed to the scanner, 
# Put one key=value per line, example:
# sonar.exclusions=**/*.bin
sonar.cpd.exclusions=**/AssemblyInfo.cs,**/*.g.cs, **/Migrations/**/*.cs
sonar.cs.vscoveragexml.reportsPaths=$(Agent.TempDirectory)/**/*.coveragexml
sonar.cs.vstest.reportsPaths=$(Agent.TempDirectory)/**/*.trx
# the full path location of the converted file
sonar.externalIssuesReportPaths=dependancy-results.json

Now the OWASP Dependency Checker vulnerabilities appear in SonarCloud, but with a few limitations

• Issues cannot be managed within SonarCloud; for instance, there is no ability to mark them as False Positive.
• The activation of the rules that raise these issues cannot be managed within SonarCloud.
• External rules are not visible on the Rules page or reflected in any Quality Profile.
• My script only does a simple mapping of the different issue formats - but this could be modified to meet any other specific needs
• Issues have to be mapped to a file already under analysis, you can’t have general project issues.

That all said, I think this is a nice solution to having a single dashboard for monitoring all my software supply chain issues.

A better option these days is to look at the AZ CLI and specifically the azure-devops extension, as this does much of the heavy lifting for you.

This does not mean that everything is plain sailing though. Today I hit a problem that took me a while to solve.

Today, I wanted to use the AZ CLI to remove assigned identity from a work item.

There is a parameter to assign the WI owner on the az boards work-item update command

az boards work-item update --id 123 --assigned-to myname

But I could not find a way to pass a null/empty/unassigned to clear this value.

In the end I found the answer was to use the following form, editing the field by name

az boards work-item update --id 123 --fields "System.AssignedTo="

Note, that there is nothing after the =, no space, null or empty quotes (and yes I had tried all of those first)

Hope this post means someone gets to this solution quicker than I did.

The Problem

The system in question was a 10 year old setup made up of a Dell Optiplex desktop currently running Windows 10 and an HP M1132 LaserJet multifunction printer. This had all been working until a couple of weeks ago when the PC failed to detect the printer. The printer was uninstalled, assuming that would fix the problem, but the Add Printer tools could not even find the printer.

I tried all the normal things, power cycle everything, swap the USB cable, reinstalling drivers, tested the printer on my Windows 11 laptop, all to no effect.

I was close to giving up, assuming the USB circuitry on the printer must have failed. However, just before I gave up, I noticed that when you plugged the USB printer cable in a DVD was detected by the PC. HP used this means, or at least did 10 years ago, to ship the drivers and other HP bloatware they deemed necessary. Until recently after this DVD was detected, Windows when onto detecting the printer. It was this second step that had failed, and I suspect the cause was a recent Windows (10 & 11) Security Update.

The Solution

Turns out the solution was in the HP Support Forum, but it took some finding as the forums are full of wrong answer, half solutions and confusion.

Basically you need to run a utility that disable the HP Smart Install DVD feature, so the printer does not appear as a DVD. Once this was done the expected Windows Add Printer Wizard worked as expected.

So that was two hours of my life I won’t get back, and I do wonder how many older HP printers will end up landfill due to what I assume is a Windows Security update to block some autorun run vulnerability?

Everything upgraded without any major issue until the final step to .NET 6. As soon as I did this my MVC pages failed to render, but no error was reported

After much fiddling the solution to the problem was pointed out to me by one of my colleagues. The way MVC is shipped with .NET (Core) has changed from being a NuGet package to being part of the framework. This happened a good while ago, but become a blocking issue with .NET Core.

The fix was in the end simple, to remove the NuGet package references to the Microsoft.AspNetCore.* 2.2.0. Once this was done the unedited MVC pages loaded using the previous working methods. I did do some further tidying to use the current MVC controller methods, but this was not essential as the old methods are now just alias for the new methods.

So the lesson learnt?

Pay more attention to the various ‘Migrate from version of .NET Core to a later version steps’ documents, and don’t put off making changes for soon to be deprecated features, as it will trip you up in a confusing manner later.

Now this page had been created a long time ago by a user who had since left the company, and this was the root cause. It seems there is an issue with Umbraco and deleted users. To avoid this problem, it is actually recommended you disable old Umbraco user accounts as opposed to deleting them.

The fix was a bit of SQL to reassign the problem node to a valid user ID

update [dbo].[umbracoNode] set nodeUser = 8  where where id = 1119

Once this script was run, and I restarted the Azure hosted Web-App, to reload the cache, I was able to edit the problematic node

The solution I ended up with was Azure Logic Apps.

I created a Logic App with a scheduled triggered that checked my blogs’s RSS feed every 30 minutes. If it found the RSS feed had been updated, I then created a bitly link for the new post’s URL, then posts to Email (as a test), Twitter and LinkedIn.

The really nice thing is this is done with built in Logic App connectors, so was quick an easy to create.

Over the years, the Black Marble blog server has been hosted on many platforms. It’s previous incarnation was WordPress, running as a network of sites with an aggregated feed. Of late we had found this slow to serve the first page (due to website start-up time) and there was the constant need to keep the instance patched.

The time had come for a new solutions, and we picked Hugo Static Pages.

Migration Process

The process to migrate our content was not as hard as I had feared.

1. The main (aggregate of all active sites) blog was exported using Wordpress’s export feature as an XML file.
2. The read only archives of blogs of ex. staff were individually exported, as they did not appear in the aggregate export file.
3. The exported XML content was converted to markdown using blog2md. Note: that a small edit was made to the blog2md tool to place the contents of each sub blog in a separate folder
4. I wrote a PowerShell script to add an alias entry to each file so the old Wordpress permalinks were still valid.
5. A new Hugo blog was created using the hugo-clarity theme as this was a nice clean blog style theme.
6. I copied the exported folders (created by blog2md) into the content folder of the new site
7. I copied the wp_content/uploads folder structure containing all the Wordpress uploaded images to the static folder of the new site. This allowed any images to be found without the need to edit the <image src=... settings in the post files.
8. Edited the Hugo site to
   • Update styles/images to our branding
   • Removed sample site pages we did not need
   • Add a data structure to define the blogs on our site e.g. name, titles, github IDs etc.
   • Created a page to list the blogs based on the new data file.
   • Edited the partial html blocks to render the RHS pane as we needed it.

The site could now be tested locally. The next step was to publish it to Azure.

Hosting

We had planned to use Azure Static Web Sites to do the hosting as these are cheap, fast and the process is well documented. However we had a problem, our site was too big.

The largest site allowed in Azure Static Web Sites is 500Mb, our blog site was over 1Gb with the numerous pages and associated image content. Hugo generated sites are not small.

This meant we had to host the site in an Azure Web Site, we picked a Linux one, set to run PHP8. This setting is required because the Linux Web Site must have some execution engine selected, even though you are not using it. In effect enabling nginx. If this is not done then the static pages are not shown. There is a further issue with this type of hosting, related to nginx’s handling of trailing slashes in URLs. The fix suggested here addressed the problem.

The move to a Azure Web Site necessitated editing the Azure Static Web Site generated Azure DevOps Pipeline. We ended up with a Pipeline that

1. Clone the repo
2. Downloads the Hugo tools
3. Runs the Hugo command to generate the static pages
4. Zip’s up the generated pages
5. Uses Bicep to build the Azure Web Site
6. Uses Zip deployment to push the pages to the site.

Summary

I am really pleased with this migration. We have ended up with a faster site with a far lower running and maintenance cost.

It was no where near as hard as I had feared, given we had a aggregated network of sites; and we managed to keep all the old permalinks with the exception of the RSS file with changed form /feed/ to /feed.xml, but I can live with that. We don’t see much RSS usage these days anyway.

So all in all well worth the effort.

The first issue was I gave it a tiny data disk, this was down to me making a typo in my GB to Bytes conversion when specifying the size. Interestingly, the GHES setup does not initially complain but sits on the ‘reloading system services’ stage until it times out. If you check the /setup/config.log you see many Nomad related 500 errors. A reboot of the VM showed the real problem, the log then showed plenty of out-of-disk space messages.

reloading system devices does take a while

The easiest fix was to just start again with a data disk of a reasonable size

I next hit the problems due to my skimping on resources. I am not sure why I chose to limit them, old habits of using systems with scarce resources I guess.

I had only given the VM 10Gb of memory and 1 CPU. The Hyper-V host was not production-grade, but could certainly supply more than that.

• The lack of at least 14Gb causes the GHES to fail to boot with a nice clear error message
• The single CPU meant the ‘reloading application services’ step fails, the /setup/config.log shows the message

Task Group "treelights" (failed to place 1 allocation):  
* Resources exhausted on 1 nodes  
* Dimension "cpu" exhausted on 1 nodes

As soon as I stopped the VM and provided 14Gb of memory and multiple vCPU to the VM instance and rebooted the setup completed as expected.

So the top tip is to read the GHES systems requirements and actually follow them, even if it is just a test/demo instance.

This was the case with a recent PR to update jest-circus to 28.x. The PR failed with the error

TypeError: Cannot read property ’enableGlobally’ of undefined at jestAdapter (node_modules/jest-circus/build/legacy-code-todo-rewrite/jestAdapter.js:39:25) at TestScheduler.scheduleTests (node_modules/@jest/core/build/TestScheduler.js:333:13) at runJest (node_modules/@jest/core/build/runJest.js:404:19) at _run10000 (node_modules/@jest/core/build/cli/index.js:320:7) at runCLI (node_modules/@jest/core/build/cli/index.js:173:3)

In the end, the fix was simple, make sure all the other Jest related packages were updated to 28.x versions. Once I did this, using a GitHub Codespace, the PR merged without a problem.

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. This was set to only allow use of Azure DevOps Templates on a given branch. The edit that had been done to the YAML meant it was trying to extend a template in a branch that was not in the approved list.

As soon as the working branch was added to the proved list it all worked as expected.

So if you see “Job is pending” errors with no obvious reason, check the environment approvals and checks. Remember, any issues with these don’t show up in the build log

I have recently come across another edge case to add to the list of gotchas.

It seems you cannot use stagedependencies to access a variable declared in a deployment job i.e. when you are using an environment to get approval for a release.

The workaround is to add a job that is dependent on the deployment and set the custom variable within it. This variable can be accessed by a later stage as shown below

- stage: S1
  jobs:
  - deployment: D1
    strategy:
      runOnce:
        deploy:
          steps:
              - checkout: none
              - bash: echo "Can't access the variable if set in here"
  - job: J1
    dependsOn:
      D1
    steps:
      - checkout: none
      - bash: echo "##vso[task.setvariable variable=myvar;isOutput=true]True" 
        name: BashStep

- stage: S2
  condition: always()

  dependsOn: 
   - S1
  jobs:
   - job: Use_Variable
     variables: # add an alias for the var
       myvar: $[stagedependencies.S1.J1.outputs['BashStep.myvar']]
        steps:
          - checkout: none
          - dash: echo "Script gets run when myvar is true"
            condition: eq (variables['myvar'],'True')

I had an error when trying to digitally sign a package. On searching on the error code I came across my own blog post with the solution. This was, as usual, one I had no recollection of writing.

I find this happens all the time. It is a little disturbing when you search for an issue and the only reference is to a post you made and have forgotten, so you are the defacto expert, nobody knows anymore on the subject, but better than having no solution.

Too often I ask people if they have documented the hints, tips and solutions they find and the response I get is ‘I will remember’. Trust me you won’t. Write something down where it is discoverable for your team and your future self. This can be any format that works for you: an Email, OneNote, a Wiki or the one I find most useful a blog. Just make sure it is easily searchable.

Your future self will thank you.

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. Hence, they are critical to creating complex pipelines.

Stage Dependency variables are the way you can pass variables from one stage to another. Special handling is required, as you can’t just use the ordinary output variables (which are in effect environment variables on the agent) as you might within a job as there is no guarantee the stages and jobs are running on the same agent.

For stage dependency variables, is not how you create output variables, that does not differ from the standard manner, the difference is in how you retrieve them.

In my sample, I used a BASH script to set the output variable based on a parameter passed into the pipeline, but you can create output variables using scripts or tasks

 - stage: SetupStage
    displayName: 'Setup Stage'
    jobs:
      - job: SetupJob
        displayName: 'Setup Job'
        steps:
          - checkout: none
          - bash:  |
              set -e # need to avoid trailing " being added to the variable https://github.com/microsoft/azure-pipelines-tasks/issues/10331
              echo "##vso[task.setvariable variable=MyVar;isOutput=true]${{parameters.value}}"
            name: SetupStep
            displayName: 'Setup Step' 

Possible ways to access a stage dependency variable

There are two basic ways to access stage dependency variables, both using array objects

stageDependencies.STAGENAME.JOBNAME.outputs['STEPNAME.VARNAME']
dependencies.STAGENAME.outputs['JOBNAME.STEPNAME.VARNAME']

Which one you use, in which place, and whether via a local alias is the complexity

How to access a stage dependency in a script?

To access a stage dependency variable in a script, or a task, there are two key requirements

• The stage containing the consuming job and hence script/task, must be set as dependant on the stage that created the output variable
• You have to declare a local alias for the value in the stageDependencies array within the consuming stage. This local alias will be used as the local name by scripts and tasks

Once this is configured you can access the variable like any other local YAML variable

 - stage: Show_With_Dependancy
    displayName: ‘Show Stage With dependancy’
    dependsOn:
      - SetupStage
    variables:
      localMyVarViaStageDependancies : $[stageDependencies.SetupStage.SetupJob.outputs[‘SetupStep.MyVar’]]
    jobs:
      - job: Job
        displayName: ‘Show Job With dependancy’
        steps:
        - bash: |
              echo “localMyVarViaStageDependancies - $(localMyVarViaStageDependancies)” 

Tip: If you are having a problem with the value not being set for a stage dependency variable look in the pipeline execution log, at the job level, and check the ‘Job preparation parameters’ section to see what is being evaluated. This will show if you are using the wrong array object, or have a typo, as any incorrect declarations evaluate as null

How to use a stage dependency as a stage condition

You can use stage dependency variables as controlling conditions for running a stage. In this use-case you use the dependencies array and not the stagedependencies used when aliasing variables.

 - stage: Show_With_Dependancy_Condition
    condition: and (succeeded(), eq (dependencies.SetupStage.outputs['SetupJob.SetupStep.MyVar'], 'True'))
    displayName: 'Show Stage With dependancy Condition' 

From my experiments for this use-case, you don’t seem to need the DependsOn entry to decare the stage that exposed the output variable for this to work. So, this is very useful for complex pipelines where you want to skip a later stage based on a much earlier stage for which there is no direct dependency.

A side effect of using a stage condition is that many subsequent stages have to have their execution conditions edited as you cannot rely on the default completion stage state succeeded. This is because the prior stages could now be succeeded or skipped. Hence all following stages need to use the condition

condition: and( not(failed()), not(canceled()))

How to use a stage dependency as a job condition

To avoid the need to alter all the subsequent stage’s execution conditions you can set a condition at the job or task level. Unlike setting the condition at that stage level, you have to create a local alias (see above) and check the condition on that

 - stage: Show_With_Dependancy_Condition_Job
    displayName: 'Show Stage With dependancy Condition'
    dependsOn:
      - SetupStage
    variables:
      localMyVarViaStageDependancies : $[stageDependencies.SetupStage.SetupJob.outputs['SetupStep.MyVar']]
    jobs:
      - job: Job
        condition: and (succeeded(),
          eq (variables.localMyVarViaStageDependancies, 'True'))
        displayName: 'Show Job With dependancy' 

This technique will work for both Agent-based and Agent-Less (Server) jobs

A warning though, if your job makes use of an environment with a manual approval, the environment approval check is evaluated before the job condition. This is probably not what you are after, so if using conditions with environments that use manual approvals then the condition is probably best set at the stage level, with the knock-on issues of states of subsequent stages as mentioned above.

An alternative, if you are just using the environment for manual approval, is to look at using an AgentLess job with a manual approval. AgentLess job manual approvals are evaluated after the job condition, so do not suffer the same problem.

If you need to use a stage dependency variable in a later stage, as a job condition or script variable, but do not wish to add a direct dependency between the stages, you could consider ‘republishing’ the variable as an output of the intermedia stage(s)

 - stage: Intermediate_Stage
    dependsOn:
      - SetUpStage
    variables:
      localMyVarViaStageDependancies : $[stageDependencies.SetupStage.SetupJob.outputs['SetupStep.MyVar']]
    jobs:
      - job: RepublishMyVar
       steps:
          - checkout: none
          - bash:  |
              set -e # need to avoid trailing " being added to the variable https://github.com/microsoft/azure-pipelines-tasks/issues/10331
              echo "##vso[task.setvariable variable=MyVar;isOutput=true]$( localMyVarViaStageDependancies)"
            name: RepublishStep 

Summing Up

So I hope this post will help you, and the future me, navigate the complexities of stage variables

You can find the YAML for the test harness I have been using in this GitHub GIST

az repos policy approver-count update --project <projectname> --blocking true --enabled true --branch main --repository-id <guid> --minimum-approver-count w --reset-on-source-push true  --creator-vote-counts false --allow-downvotes false 

However, you hit a problem if you wish to set the ‘All Repositories’ policies for a Team Project. The issue is that the above command requires a specific --project parameter.

I can find no way around this using any published CLI tools, but using the REST API there is an option.

You could of course check the API documentation to work out the exact call and payload. However, I usually find it quicker to perform the action I require in the Azure DevOps UI and monitor the network traffic in the browser developer tools to see what calls are made to the API.

Using this technique, I have created the following script that sets the All Repositories branch policies.

Note that you can use this same script to set a specific repo’s branch policies by setting the repositoryId in the JSON payloads.

Today I came across a strange issue with a reasonably old multi-stage YAML pipeline, it appeared to be cancelling itself.

The Build stage ran OK, but the Release stage kept being shown as cancelled with a strange error. The strangest thing was it did not happen all the time. I guess this is the reason the problem had not been picked up sooner.

If I looked at the logs for the Release stage, I saw that the main job, and meant to be the only job, had completed successfully. But I had gained an extra unexpected job that was being cancelled in 90+% of my runs.

This extra job was trying to run on an Ubuntu hosted agent and failing to make a connection. All very strange as all the jobs were meant to be using private Windows-based agents.

The Solution

Turns out, as you might expect, the issue was a typo in the YAML.

- stage: Release
  dependsOn: Build
  condition: succeeded()
  jobs:
  **- job:**
  - template: releasenugetpackage.yml@YAMLTemplates
    parameters:

The problem was the stray job: line. This was causing the attempt to connect to a hosted agent and then check out the code. Interesting a hosted Ubuntu agent was requested given there was no Pool defined

As soon as the extra line was removed the problems went away.

When you link SonarQube into an Azure DevOps pipeline that is used from branch protection the success, or failure, of the PR branch analysis is shown as an optional PR Check

The question was ‘how to do I make it a required check?’. Turns out the answer is to add an extra Azure DevOps branch policey status check for the ‘SonarQube/quality gate’

When you press the + (add) button it turns out the ‘SonarQube/quality gate’ is available in the drop-down

Once this change was made, the SonarQube Quality Check becomes a required PR Check.

We regularly re-build our Azure DevOps private agents using Packer and Lability, as I have posted about before.

Since the latest re-build, we have seen all sorts of problems. All related to pulling packages and tools from NuGet based repositories. Problems we have never seen with any previous generation of our agents.

The Issue

The issue turned out to be related to registering a private PowerShell repository.

$RegisterSplat = @{
Name = 'PrivateRepo'
SourceLocation = 'https://psgallery.mydomain.co.uk/nuget/PowerShell'
PublishLocation = 'https://psgallery.mydomain.co.uk/nuget/PowerShell'
InstallationPolicy = 'Trusted'
}

Register-PSRepository @RegisterSplat

Running this command caused the default dotnet NuGet repository to be unregistered i.e. the command dotnet nuget list source was expected to return

Registered Sources:
  1.  PrivateRepo
      https://psgallery.mydomain.co.uk/nuget/Nuget
  2.  nuget.org [Enabled]
      https://www.nuget.org/api/v2/
  3.  Microsoft Visual Studio Offline Packages [Enabled]
      C:Program Files (x86)Microsoft SDKsNuGetPackages 

But it returned

Registered Sources:
  1.  PrivateRepo
      https://psgallery.mydomain.co.uk/nuget/Nuget
  2.  Microsoft Visual Studio Offline Packages [Enabled]
      C:Program Files (x86)Microsoft SDKsNuGetPackages

The Workaround

You can’t call this a solution, as I cannot see why it is really needed, but the following command does fix the problem

 dotnet nuget add source https://api.nuget.org/v3/index.json -n nuget.org

To make this process easier, quicker and more consistent I have developed a process to automated all of this work. It uses a mixture of the following:

A sample team project that contains a Git repo containing the base code I want in my new Team Project’s default Git repo. In my case this includes

• An empty Azure Resource Management (ARM) template
• A .NET Core Hello World console app with an associated .NET Core Unit Test project
• A YAML pipeline to build and test the above items, as well as generating release notes into the Team Project WIKI

A PowerShell script that uses both az devops and the Azure DevOps REST API to

• Create a new Team Project
• Import the sample project Git repo into the new Team Project
• Create a WIKI in the new Team Project
• Add a SonarQube/SonarCloud Service Endpoint
• Update the YAML file for the pipeline to point to the newly created project resources
• Update the branch protection rules
• Grant access privaledges as needed for service accounts

The script is far from perfect, it could do much more, but for me, it does the core requirements I need.

You could of course enhance it as required, removing features you don’t need and adding code to do jobs such as adding any standard Work Items you require at the start of a project. Or altering the contents of the sample repo to be cloned to better match your most common project needs.

You can find the PowerShell script in AzureDevOpsPowershell GitHub repo, hope you find it useful.

Background

My YAML pipeline included a manual approval to allow deployment to a given environment. Within the stage protected by the approval, I needed the approver’s details, specifically their email address.

I managed to achieve this but had to use undocumented API calls. These were discovered by looking at Azure DevOps UI operations using development tools within my browser.

The Solution

The process was as follows

• Make a call to the build’s timeline to get the current stage’s GUID - this is documented API call
• Make a call to the Contribution/HierarchyQuery API to get the approver details. This is the undocumented API call.

The code to do this is as shown below. It makes use of predefined variables to pass in the details of the current run and stage.

Note that I had to re-create the web client object between each API call. If I did not do this I got a 400 Bad Request on the second API call - it took me ages to figure this out!

I have read plenty of documentation and even tried swapping to use SQL Server, as opposed to SQLite, but this just resulted in the error ‘There is already an open DataReader associated with this Connection which must be closed first.’.

So everything pointed to it being a mistake I had made.

And it was, it turns out the issue was I had the dbContext.SaveChanges() call inside a foreach loop

It was

using (var dbContext = scope.ServiceProvider.GetRequiredService()) {
    var itemsToQueue = dbContext.CopyOperations.Where(o => o.RequestedStartTime < DateTime.UtcNow && o.Status == OperationStatus.Queued);
    foreach (var item in itemsToQueue) {
        item.Status = OperationStatus.StartRequested;
        item.StartTime = DateTime.UtcNow;
        dbContext.SaveChanges();
    }
}

And it should have been

 using (var dbContext = scope.ServiceProvider.GetRequiredService()) {
    var itemsToQueue = dbContext.CopyOperations.Where(o => o.RequestedStartTime < DateTime.UtcNow && o.Status == OperationStatus.Queued);
    foreach (var item in itemsToQueue) {
        item.Status = OperationStatus.StartRequested;
        item.StartTime = DateTime.UtcNow;
    }
    dbContext.SaveChanges();
}

Once this change was made my error disappeared.

• A new Azure DevOps region has become available since you created your organisation that is a ‘better home’ for your projects.
• New or changing national regulations require your source stored in a specific location.
• You want your repositories as close to your workers as possible, to reduce network latency.

One of these reasons meant I recently had to move an Azure DevOps organisation, so followed the documented process. This requires you to

1. Whilst logged in as the Azure DevOps organisation owner, open the Azure DevOps Virtual Support Agent
2. Select the quick action ‘Change Organization Region’
3. Follow the wizard to pick the new region and the date for the move.

You are warned that there could be a short loss of service during the move. Much of the move is done as a background process. It is only the final switch over that can interrupt service, hence this interruption being short.

I followed this process, but after the planned move date I found my organisation has not moved. In the Virtual Support Agent, I found the message.

Please note that region move requests are currently delayed due to ongoing deployments. We may not be able to perform the change at your requested time and may ask you to reschedule. We apologize for the potential delay and appreciate your patience!

I received no other emails, I suspect overly aggressive spam filters were the cause of that, but it meant I was unclear what to do next. Should I:

1. Just wait i.e. do not reschedule anything, even though the target date is now in the past
2. Reschedule the existing move request to a date in the future using the virtual assistant wizard
3. Cancel the old request and start the process again from scratch

After asking the question in the Visual Studio Developer Community Forums I was told the correct action is to cancel the old request and request a new move date. It seems that once your requested date is passed the move will not take place no matter how long you wait.

Hence, I created a new request, which all went through exactly as planned.

The key steps you need to remember are as follows

Desktop Interaction

The build agent should not be running as a service it must be able to interact with the desktop.

If you did not set this mode during configuration this post from Donovan Brown shows how to swap the agent over without a complete reconfiguration.

Test Assemblies

The UWP unit test projects are not built as a DLL, but as an EXE.

I stupidly just made my VSTest task look for the generated EXE and run the tests they contained. This does not work generating the somewhat confusing error

Test run will use DLL(s) built for framework .NETFramework,Version=v4.0 and platform X86. Following DLL(s) do not match framework/platform settings.
BlackMarble.Spectrum.FridgeManagement.Client.OneWire.UnitTests.exe is built for Framework .NETCore,Version=v5.0 and Platform X86.

What you should search for as the entry point for the tests is the .appxrecipe file. Once tI used this my tests ran.

So my pipeline YML to run all the tests in a built solutions was

- task: VisualStudioTestPlatformInstaller@1
   inputs:
      packageFeedSelector: 'nugetOrg'
      versionSelector: 'latestPreRelease'              
- task: VSTest@2
    displayName: 'VSTest - testAssemblies'
    inputs:
       platform: 'x86'
       configuration: '$(BuildConfiguration)'
       testSelector: 'testAssemblies' 
testAssemblyVer2: | # Required when testSelector == TestAssemblies
         ***unittests.dll
        ***unittests.build.appxrecipe
         !***TestAdapter.dll
         !**obj** 
       searchFolder: '$(Build.SourcesDirectory)/src'
       resultsFolder: '$(System.DefaultWorkingDirectory)TestResults'
       runInParallel: false
       codeCoverageEnabled: true
       rerunFailedTests: false
       runTestsInIsolation: true
       runOnlyImpactedTests: false
         - task: PublishTestResults@2
   displayName: 'Publish Test Results **/TEST-*.xml'
  condition: always()

The easiest way to set the environment variable `SONAR_SCANNER_OPTS` on every build agent is to just set it via a Azure Pipeline variable. This works because the build agent makes all pipeline variables available as environment variables at runtime.

So as I was using YML Pipeline, I set a variable within the build job

- `job: build
timeoutInMinutes: 240
variables:

• name: BuildConfiguration
  value: ‘Release’
• name: SONAR_SCANNER_OPTS
  value: -Xmx4096m
  steps:`

I found I had to quadruple the memory allocated to the scanner. Once this was done my analysis completed

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. As noted in the documentation there are different ways to access a variable…

In a pipeline, template expression variables ${{ variables.var }} get processed at compile time, before runtime starts. Macro syntax variables $(var) get processed during runtime before a task runs. Runtime expressions $[variables.var] also get processed during runtime but were designed for use with conditions and expressions.

Azure DevOps Documentation

99% of the time I have been fine using just the $(var) syntax, but I recently was working on a case where this would not work for me.

The Issue

I had a pipeline that made heavy use of YML templates and conditional task insertion to include sets of task based upon the manually entered and pre-defined variables.

The problems that one of the tasks, used in a template, set a boolean output variable $(outVar) by calling

echo '##vso\[task.setvariable variable=outvar;isOutput=true\]true'

This task created the output variable could be accessed by other tasks as the variable $(mytask.outvar), but it was set at runtime it not available at the time of the YML compilation.

This caused me a problem as it meant that it could not be used in the template’s conditional task inclusion blocks as it as not present art compile time when this code is evaluated e.g.

\- ${{ if eq(mytask.outvar, 'true') }} :
  # the task to run if the condition is met
  - task: Some.Task@1 
    ....

I tied referencing the variable using all forms of $ followed by brackets syntax I could think of, but it did not help.

The lesson here is that you cannot make a runtime value a compile time value by wishing it to change.

The only solution I could find was to make use of the runtime variable in a place where it can be resolved. If you wish to enable or disable a task based on the variable value then the only option is to use the condition parameter

  # the task to run if the condition is met
  - task: Some.Task@1 
    condition: and(succeeded(), eq(mytask.outvar, 'true'))
    ....

The only downside of this way of working as opposed to the conditional insertion is that

• If you conditional insertion, non required tasks are never shown in the pipeline as they are not compiled into it
• If using the condition property to exclude a task, it will still appear in the log, but it can be seen that it has not been run.

So I got there in the end, it was just not as neat as I had hoped, but I do have a clearer understanding of compile and runtime variables in Azure DevOps YML

If you are migrating your Azure DevOps Classic Builds and Release to Multi-Stage YAML then an import step is to export all the exiting build, task groups and release as YAML files.

You can do this by hand within the Pipeline UI, with a lot of cut and pasting, but much easier is to use the excellent Yamlizr - Azure DevOps Classic-to-YAML Pipelines CLI from Alex Vincent. A single CLI command exports everything with a Team project into a neat folder structure of template base YAML.

I cannot recommend the tool enough

The pen, when it works, has worked well. However, the problem has been that whether the pen and PC detected each other seemed very hit and miss.

Today I found the root cause. It was not drivers or dodgy Bluetooth as I had thought, but a weak spring inside the pen. It was not so weak that the battery rattled, but weak enough that the electrical circuit was not being closed reliably on the battery.

The fix was to replace the weak spring with new one out of an old ball point pen. Once this was done the pen became instantly reliable.

Wish I had spotted that sooner.

Updated 11 Nov 2020: I may have spoken too soon, it is back to it’s old behaviour today :(

However, I think it could just be the AAAA battery. Seems it is not a good idea to leave a battery in when the pen is not is use given the pen has no power switch.

I have recently had need, for the first time since swapping my default branch name in new repos to main, to use Semantic Version and the GitVersion tool.

‘Out of the box’ I hit a problem. The current shipping version of GitVersion (5.3.2) by default makes the assumption that’s the trunk branch is called master. Hence, throws an exception if this branch cannot be found.

Looking at the project’s repo you can find PRs, tagged for a future release, that address this constraint. However, you don’t have to wait for a new version to ship to use this excellent tool in repos with other branch naming conventions.

The solution is to create an override file GitVersion.yml in the root of your repo with the following content to alter the Regex used to find branches. Note that the content below is as a minimum, you can override any other default configuration values in this file as needed.

branches:  
   master:  
      regex: ^master$|^main$

With this override file the default branch can be either master or main.

You can of course use a different name or limit the Regex to a single name as you need.

This works well if all the YAML files are in the same repo, but not so well if you are using YAML templates and the templated YAML is stored in a different repo. This is because an Azure DevOps PR is limited to a single repo. So testing a change to a YAML template in a different repo needs a bit of thought.

Say for example you have a template called core.yml in a repo called YAMLTemplates and you make a change to it and start a PR. Unless you have a test YAML pipeline in that repo, which is not a stupid idea, but not always possible depending on the complexity of your build process, there is no way to test the change inside that repo.

The answer is to create a temporary branch in a repo that consumes the shared YAML template. In this temporary branch make an edit to the repository setting that references the shared YAML repo to point to the update branch contain the PR

resources: 
repositories:
  - repository: YAMLTemplates
   type: git
   name: 'Git Project/YAMLTemplates'
# defaults to ref: 'refs/heads/master'
ref: 'refs/heads/newbranch'

You don’t need to make any change to the line where the template is used

extends:  
template: core.yml@YAMLTemplates
  parameters:
    customer: ${{parameters.Customer}}
    useSonarQube: ${{parameters.useSonarQube}}

You can then use this updated pipeline to validated your PR. Once you are happy it works you can

1. Complete the PR in the YAML Templates repo
2. Delete the temporary branch in your consuming repo.

Well it is for just this requirement that I have written a set of Azure DevOps Pipeline Tasks

• Release Note Generator - to generate release notes. I strongly recommend this Cross-platform Node-based version. I plan to deprecate my older PowerShell version in the not too distant future as it uses ‘homegrown logic’, as opposed to standard Azure DevOps API calls, to get associated items.
• Wiki Updater - to upload a page tot a WIKI.
• WIKI PDF Generator - to convert a generated page, or whole WIKI, to PDF format.

So lets deal with these tools in turn

Generating Release Notes

The Release Note task generates release notes by getting the items associated with a build (or release) from the Azure DevOps API and generating a document based on a Handlebars based template.

• The artefacts that can be included in the release notes are details of the build/release and associated Work Items, Commits/Changesets, Tests and Pull Requests.
• Most of the sample templates provided are for markdown format files. However, they could easily be converted for other text-based formats such as HTML if needed.
• The use of Handlebars are the templating language makes for a very flexible and easily extensible means of document generation. There are sample of custom extensions provided with the templates

Sample YAML for this task is as follows, not it is using an inline template but it is possible to also load the template from a file path

 - task: richardfennellBM.BM-VSTS-XplatGenerateReleaseNotes.XplatGenerate-Release-Notes.XplatGenerateReleaseNotes@3
          displayName: 'Generate Release Notes'
          inputs:
            outputfile: '$(System.DefaultWorkingDirectory)inline.md'
            outputVariableName: OutputText
            templateLocation: InLine
            inlinetemplate: |
              # Notes for build 
              **Build Number**: {{buildDetails.id}}
              **Build Trigger PR Number**: {{lookup buildDetails.triggerInfo 'pr.number'}} 

              # Associated Pull Requests ({{pullRequests.length}})
              {{#forEach pullRequests}}
              {{#if isFirst}}### Associated Pull Requests (only shown if  PR) {{/if}}
              *  **PR {{this.id}}**  {{this.title}}
              {{/forEach}}

              # Builds with associated WI/CS ({{builds.length}})
              {{#forEach builds}}
              {{#if isFirst}}## Builds {{/if}}
              ##  Build {{this.build.buildNumber}}
              {{#forEach this.commits}}
              {{#if isFirst}}### Commits {{/if}}
              - CS {{this.id}}
              {{/forEach}}
              {{#forEach this.workitems}}
              {{#if isFirst}}### Workitems {{/if}}
              - WI {{this.id}}
              {{/forEach}} 
              {{/forEach}}

              # Global list of WI ({{workItems.length}})
              {{#forEach workItems}}
              {{#if isFirst}}## Associated Work Items (only shown if  WI) {{/if}}
              *  **{{this.id}}**  {{lookup this.fields 'System.Title'}}
                - **WIT** {{lookup this.fields 'System.WorkItemType'}} 
                - **Tags** {{lookup this.fields 'System.Tags'}}
              {{/forEach}}

              {{#forEach commits}}
              {{#if isFirst}}### Associated commits{{/if}}
              * ** ID{{this.id}}** 
                -  **Message:** {{this.message}}
                -  **Commited by:** {{this.author.displayName}} 
                -  **FileCount:** {{this.changes.length}} 
              {{#forEach this.changes}}
                    -  **File path (TFVC or TfsGit):** {{this.item.path}}  
                    -  **File filename (GitHub):** {{this.filename}}  
              {{/forEach}}
              {{/forEach}}

How to Publish The Notes

Once the document has been generated there is a need for a decision as to how to publish it. TThere are a few options

• Attach the markdown file as an artefact to the Build or Pipeline. Note you can’t do this with a UI based Releases as they have no concept of artefacts, but this is becoming less of a concern as people move to multistage YAML.
• Save in some other location e.g Azure Storage or if on-premises a UNC file share
• Send the document as an email – I have used Rene van Osnabrugge Send Email Task for this job.
• Upload it to a WIKI using my WIKI Updater Task
• Convert the markdown release note document, or the whole WIKI, to a PDF and use any of the above options using first my WIKI PDF Exporter Task then another task.

I personally favour the 1st and 4th options used together. Attachment to the pipeline and then upload the document to a WIKI

A sample of suitable YAML is shown below, uploading the document to an Azure DevOps WIKI. Please note that the repo URL and authentication can trip you up here so have a good read of the provided documentation before you use this task.

 - task: richardfennellBM.BM-VSTS-WIKIUpdater-Tasks.WikiUpdaterTask.WikiUpdaterTask@1
          displayName: 'Git based WIKI Updater'
          inputs:
            repo: 'dev.azure.com/richardfennell/Git%20project/_git/Git-project.wiki'
            filename: 'xPlatReleaseNotes/build-Windows-handlebars.md'
            dataIsFile: true
            sourceFile: '$(System.DefaultWorkingDirectory)inline.md'
            message: 'Update from Build'
            gitname: builduser
            gitemail: 'build@demo'
            useAgentToken: true

But when do I generate the release notes?

I would suggest you always generate release notes every build/pipeline i.e. a document of the changes since the last successful build/pipeline of that build definition. This should be attached as an artefact.

However, this per build document will usually too granular for use as ‘true’ release notes i.e. something to hand to a QA team, auditor or client.

To address this second use case I suggest, within a multistage YAML pipeline (or a UI based release), having a stage specifically for generating release notes.

My task has a feature that it will check for the last successful release of a pipeline/release to the stage it is defined in, so will base the release note on the last successful release to that given stage. If this ‘documentation’ stage is only run when you are doing a ‘formal’ release, the release note generated will be since the last formal release. Exactly what a QA team or auditor or client might want.

In conclusion

So I hope that this post provides some ideas as to how you can use my tasks generate some useful release notes.

I have an Azure DevOps multi-stage YAML pipeline that started giving the error `The pipeline is not valid error: Unable to resolve latest version for pipeline templates: this could be due to inaccessible pipeline or no version is available` and failing instantly.

The Solution

This is not the most helpful message, but after some digging I found the problem.

The pipeline used another pipeline as a resources

resources:   
  pipelines:  
  - pipeline: templates  
    source: QueuesAndFunctionsDemo-CI    
    branch: master

This referenced build had failed, so there was no successful build resources to load, hence the error.

Once the problem with this reference build was fixed the error message went away and I could trigger my build

• Clone a WIKI Repo
• Run the command line tool passing in a path to the root of the cloned repo
• The .order file is read
• A PDF is generated

This is a nice and simple process, but it would be nice to be able to automate this process as part of a build pipeline. After a bit of thought, I realised I had much of the code I needed to automated the process in my WIKIUpdater extension as these tasks are based around cloning repos. So I am please to say I have just released a new Azure DevOps extension WikiPDFExport that wrappers Max’s command line tool. It does the following

• Downloads the latest release of the WikiPDFExport tool from GitHub to the build agent (the exe is too big to include in the VSIX package)
• Optionally clone a Git based WIKI repo. As with my WikIUpdater tasks, you can pass credentials for Azure DevOps or GitHub
• Generate a PDF of a single file or the whole of a Wiki folder structure (based on the .order file) that was either cloned or was already present on the agent

A sample of the YAML usage of the task is as shown below. For full documentation see the extensions wiki pages for general usage and troubleshooting and the full YAML specification``` - task: richardfennellBM.BM-VSTS-WikiPDFExport-Tasks.WikiPDFExportTask.WikiPdfExportTask@1 displayName: ‘Export Single File generated by the release notes task’ inputs: cloneRepo: false localpath: ‘$(System.DefaultWorkingDirectory)’ singleFile: ‘inline.md’ outputFile: ‘$(Build.ArtifactStagingDirectory)PDFsingleFile.pdf’

• task: richardfennellBM.BM-VSTS-WikiPDFExport-Tasks.WikiPDFExportTask.WikiPdfExportTask@1 displayName: ‘Export a public GitHub WIKI’ inputs: cloneRepo: true repo: ‘https://github.com/rfennell/AzurePipelines.wiki.git' useAgentToken: false localpath: ‘$(System.DefaultWorkingDirectory)GitHubRepo’ outputFile: ‘$(Build.ArtifactStagingDirectory)PDFpublicGitHub.pdf’
• task: richardfennellBM.BM-VSTS-WikiPDFExport-Tasks.WikiPDFExportTask.WikiPdfExportTask@1 displayName: ‘Export a private Azure DevOps WIKI’ inputs: cloneRepo: true repo: ‘https://dev.azure.com/richardfennell/GitHub/_git/GitHub.wiki’ useAgentToken: true localpath: ‘$(System.DefaultWorkingDirectory)AzRepo’ outputFile: ‘$(Build.ArtifactStagingDirectory)PDFAzrepo.pdf’

1. Edit the pipeline
2. Click the ellipse menu top right
3. Pick Triggers
4. Pick YAML and select the ‘Get Source’ block
5. Make sure the ‘Clean’ setting is set to ‘true’ and the right set of items to delete are selected – if this is not done the post clean up task does nothing
6. You can then add the post build cleanup task the end of the steps

steps:
  - script: echo This where you do stuff
  - task: mspremier.PostBuildCleanup.PostBuildCleanup-task.PostBuildCleanup@3
    displayName: 'Clean Agent Directories'
    condition: always()


```Once this is done it behaves as expected

Basically, Zwift itself was fine, though very slow to save when exiting, but the companion app could not seem to detect that I was actively Zwift’ing, but it’s other functions were OK.

After much fiddling I found the issue was the network connection from my PC up to Zwift and nothing to do with the phone app. But in case it is of any use to others here are the steps I took to

• Ran a WiFi network analysis app and realised that
  • My local wireless environment is now very congested, I assume as more people are working from home.
  • Both the 2.4GHz and 5Ghz network were on the same channels as other strong signals.
  • Also they were using the same SSID, which is meant to provide seamless swap-over between 2.4 and 5Ghz. But, in reality this meant there were connection problems as a connection flipped between frequencies.

This explained other problems I had seem

• The Microsoft Direct Access VPN I use to connect to the office failing intermittently. Obviously, any problems I have connecting to the office to do work is far less important than Zwift connection issues.
• My Samsung phone would drop calls for no reason. I now think this was when it had decided to use Wifi calling and got confused over networks.
  Note: I had fixed this by switching off Wifi calling.

To address the problems I changed the SSIDs so that my 2.4 and 5Ghz networks had different names, so that I know which one I was using. Also I moved the channels to ones not used by my neighbours

Test

Result

Put the phone and the PC on the 2.4Ghz network

No improvement, app did not work and PC slow to save

Put the phone and the PC on 5Ghz

Small improvement, app still did not work but at least tried to show the in game view before it dropped out. The PC was still slow to save

Put the phone on either Wifi network but the the PC on Ethernet over Power using TPLink adaptors

This fixed it

So it seems the problem was upload speed from my PC all along. Strange as I would have expected the 5Ghz network to be fine, even if the 2.4Ghz was not. The 5Ghz Wifi seems to perform OK on a speed test.

Anyway it is working now, but maybe it is time to consider a proper mesh network?

Whilst doing a migration from an on-premised TFS to Azure DevOps Services for a client I had a strange issue with SQLPackage.exe.

I had previously completed the dry run of the migration without any issues and started the live migration with a fully defined process and timings for a each stage.

When I came to export the detached Team Project Collection DB I ran the same command as I had for the dry run

& "C:Program FilesMicrosoft SQL Server150DACbinSqlPackage.exe" /sourceconnectionstring:”Data Source=localhostSQLExpress;Initial Catalog=Tfs\_DefaultCollection;Integrated Security=True” /targetFile:C:tempTfs\_DefaultCollection.dacpac /action:extract /p:ExtractAllTableData=true /p:IgnoreUserLoginMappings=true /p:IgnorePermissions=true /p:Storage=Memory 

I had expected this to take around 30 minutes. However it failed after 10 minutes with an error when trying to export the schema ‘Timeout, cannot reconnect to the database’.

This was strange as nothing had changed on the system since the dry-run. I tried all of the following with no effect

• Just running the command again, you can hope!
• Restarted SQL and ran the command again
• Tried the export from SQL Management Studio as opposed to the command line , this just seems to hang at the same point.

The Solution

What resolved the problem was a complete reboot of the virtual machine. I assume the issue was some locked resource, but not idea why.

Updated 29th July 2020

I had the same problem with another client upgrade. This time a reboot did not fix it.

The solution at this site was to upgrade SQLPackage from the 140 32bit version to the 64bit 150 version. Once this was done the command ran without 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

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.

The stages are as follows

Build

The build phase does the following

• Updates all the TASK.JSON files so that the help text has the correct version number

• Calls a YAML template (build-Node-task) that performs all the tasks to transpile a TypeScript based task – if my extension contained multiple tasks this template would be called a number of time

• Get NPM packages

• Run Snyk to check for vulnerabilities – if any vulnerabilities are found the build fails

• Lint and Transpile the TypeScript – if any issue are found the build fails

• Run any Unit test and publish results – if any test fail the build fails

• Package up the task (remove dev dependencies)

• Download the TFX client

• Package up the Extension VSIX package and publish as a pipeline artifact.

Private

The private phase does the following

• Using another YAML template (publish-extension) publish the extension to the Azure DevOps Marketplace, but with flags so it is private and only assessible to my account for testing

• Download the TFX client

• Publishes the Extension to the Marketplace

This phase is done as a deployment job and is linked to an environment,. However, there are no special approval requirements are set on this environment. This is because I am happy for the release to be done to the private instance assuming the build phase complete without error.

Test

This is where the pipeline gets interesting. The test phase does the following

• Runs any integration tests. These could be anything dependant on the extension being deployed. Unfortunately there is no option at present in multistage pipeline for a manual task to say ‘do the manual tests’, but you could simulate similar by sending an email or the like.

The clever bit here is that I don’t want this stage to run until the new private version of the extension has been published and is available; there can be a delay between TFX saying the extension is published and it being downloadable by an agent. This can cause a problem in that you think you are running tests against a different version of the extension to one you have. To get around this problem I have implemented a check on the environment this stage’s deployment job is linked to. This check runs an Azure Function to check the version of the extension in the Marketplace. This is exactly the same Azure Function I already used in my UI based pipelines to perform the same job.

The only issue here is that this Azure Function is used as an exit gate in my UI based pipelines; to not allow the pipeline to exit the private stage until the extension is publish. I cannot do this in a multistage YAML pipeline as environment checks are only done on entry to the environment. This means I have had to use an extra Test stage to associate the entry check with. This was setup as follows

• Create a new environment

• Click the ellipse (…) and pick ‘approvals and checks’

• Add a new Azure Function check

• Provide the details, documented in my previous post, to link to your Azure Function. Note that you can, in the ’control options’ section of the configuration, link to a variable group. This is a good place to store all the values, you need to provide

• URL of the Azure Function

• Key to us the function

• The function header

• The body – this one is interesting. You need to provide the build number and the GUID of a task in the extension for my Azure Function. It would be really good if both of these could be picked up from the pipeline trying to use the environment. This would allow a single ‘test’ environment to be created for use by all my extensions, in the same way there are only a single ‘private’ and ‘public’ environment. However, there is a problem, the build number is picked up OK, but as far as I can see I cannot access custom pipeline variables, so cannot get the task GUID I need dynamically. I assume this is because this environment entry check is run outside of the pipeline. The only solution  can find is to place the task GUID as a hard coded value in the check declaration (or I suppose in the variable group). The downside of this is it means I have to have an environment dedicated to each extension, each with a different task GUID. Not perfect, but not too much of a problem

• In the Advanced check the check logic

• In control options link to the variable group contain any variables used.

Documentation

The documentation stage again uses a template (generate-wiki-docs) and does the following

• Use the extension and task manifest files to generate YAML usage documentation using one of my tasks
• Uploads the extension readme file to a WIKI using another of my tasks
• Uploads the extension YAML usage file to a WIKI

Public

The public stage is also a deployment job and linked to an environment. This environment has an approval set so I have to approve any release of the public version of the extension.

As well as doing the same as private stage this stage does the following

• Same a private stage
• Send a Tweet saying I have release a new version of the extension using my Artifact Description extension to get the text of the PR
• Update the pipelines minor build number variable to make sure then I next release I have a higher build number

Summary

It took a bit of trial and error to get this going, but I think I have a good solution now. The fact that the bulk of the work is done using shared templates means I should get good reuse of the work I have done. I am sure I will be able to improve the template as time goes on but it is a good start

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

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

Luckily there is a step by step tutorial from Microsoft on how to set this up. Though, I would say that though detailed this tutorial has a strange structure in that it shows the default values not the correct values. Hence, the tutorial requires close reading, don’t just look at the pictures!

Even with close reading, I still hit a problem, all of my own making, as I went through this tutorial.

The Issue – a stray / in a URL

I entered all the AAD URLs and certs as instructed (or so I thought) by the tutorial into the Security page of GitHub Enterprise.

When I pressed the ‘Validate’ button in GitHub, to test the SSO settings, I got an error

‘The client has not listed any permissions for ‘AAD Graph’ in the requested permissions in the client’s application registration’

This sent me shown a rabbit hole looking at user permissions. That wasted a lot of time.

However, it turns out the issue was that I had a // in a URL when it should have been a  /. This was because I had made a cut and paste error when editing the tutorial’s sample URL and adding my organisation details.

Once I fixed this typo the validation worked, I was able to complete the setup and then I could to invite my AAD users to my GitHub Enterprise organisation.

Summary

So the summary is, if you follow the tutorial setting up SSO from AAD to GitHub Enterprise is easy enough to do, just be careful of over the detail.

I recently tripped myself up whist adding SonarQube analysis to a rather complex Azure DevOps build.

The build has two VsTest steps, both were using the same folder for their test result files. When the first VsTest task ran it created the expected .TRX and .COVERAGE files and then published its results to Azure DevOps, but when the second VsTest task ran it over wrote this folder, deleting the files already present, before it generated and published it results.

This meant that the build itself had all the test results published, but when SonarQube looked for the files for analysis only the second set of test were present, so its analysis was incorrect.

Solution

The solution was easy, use different folders for each set of test results.

This gave me a build, the key items are shown below, where one VsTest step does not overwrite the previous results before they can be processed by any 3rd party tasks such as SonarQube.

steps:  
- task: SonarSource.sonarqube.15B84CA1-B62F-4A2A-A403-89B77A063157.SonarQubePrepare@4  
   displayName: 'Prepare analysis on SonarQube'  
   inputs:  
     SonarQube: Sonarqube  
     projectKey: 'Services'  
     projectName: 'Services'  
     projectVersion: '$(major).$(minor)'  
     extraProperties: |  
      # Additional properties that will be passed to the scanner,   
      sonar.cs.vscoveragexml.reportsPaths=$(System.DefaultWorkingDirectory)/\*\*/\*.coveragexml  
      sonar.cs.vstest.reportsPaths=$(System.DefaultWorkingDirectory)/\*\*/\*.trx

  

… other build steps

  

\- task: VSTest@2  
   displayName: 'VsTest – Internal Services'  
   inputs:  
     testAssemblyVer2: |  
      \*\*\*.unittests.dll  
      !\*\*obj\*\*  
     searchFolder: '$(System.DefaultWorkingDirectory)/src/Services'  
     resultsFolder: '$(System.DefaultWorkingDirectory)TestResultsServices'  
     overrideTestrunParameters: '-DeploymentEnabled false'  
     codeCoverageEnabled: true  
     testRunTitle: 'Services Unit Tests'  
     diagnosticsEnabled: True  
   continueOnError: true

\- task: VSTest@2  
   displayName: 'VsTest - External'  
   inputs:  
     testAssemblyVer2: |  
      \*\*\*.unittests.dll  
      !\*\*obj\*\*  
     searchFolder: '$(System.DefaultWorkingDirectory)/src/ExternalServices'  
     resultsFolder: '$(System.DefaultWorkingDirectory)TestResultsExternalServices'  
     vsTestVersion: 15.0  
     codeCoverageEnabled: true  
     testRunTitle: 'External Services Unit Tests'  
     diagnosticsEnabled: True  
   continueOnError: true  

\- task: BlackMarble.CodeCoverage-Format-Convertor-Private.CodeCoverageFormatConvertor.CodeCoverage-Format-Convertor@1  
   displayName: 'CodeCoverage Format Convertor'  
   inputs:  
     ProjectDirectory: '$(System.DefaultWorkingDirectory)'  

\- task: SonarSource.sonarqube.6D01813A-9589-4B15-8491-8164AEB38055.SonarQubeAnalyze@4  
   displayName: 'Run Code Analysis'

\- task: SonarSource.sonarqube.291ed61f-1ee4-45d3-b1b0-bf822d9095ef.SonarQubePublish@4  
   displayName: 'Publish Quality Gate Result'  

As discussed in that post, using this model you will recreate your build agent VMs on a regular basis, as opposed to patching them. When I came to do this recently I found that the Packer image generation was failing with errors related to accessing packages.

Initially, I did not read the error message too closely and just assumed it was an intermittent issue as I had found you sometime get random timeouts with this process. However, when the problem did not go away after repeated retries I realised I had a more fundamental problem, so read the log properly!

Turns out the issue is you now have to pass a GitHub PAT token that has at least read access to the packages feed to allow Packer to authenticate with GitHub to read packages.

The process to create the required PAT is as follows

1. In a browser login to GitHub
2. Click your profile (top right)
3. Select Settings
4. Pick Developer Settings
5. Pick Personal Access Tokens and create a new one that has read:packages enabled

Once created, this PAT needs to be passed into Packer. If using the settings JSON file this is just another variable

{
"client\_id": "Azure Client ID",
"client\_secret": "Client Secret",
"tenant\_id": "Azure Tenant ID",
"subscription\_id": "Azure Sub ID",
"object\_id": "The object ID for the AAD SP",
"location": "Azure location to use",
"resource\_group": "Name of resource group that contains Storage Account",
"storage\_account": "Name of the storage account",
"ssh\_password": A password",
"install\_password": "A password",
"commit\_url": "A url to to be save in a text file on the VHD, usually the URL if commit VHD based on",

"github\_feed\_token": "A PAT"

}  

If you are running Packer within a build pipeline, as the other blog post discusses, then the PAT will be another build variable.

Once this change was made I was able to get Packer to run to completion, as expected.

The Problem

The error occurred when I tried to queue a new build after the upgrade, the build instantly failed with the error

‘The module being executed is not trusted, Either the owner of the database of the module need to be granted authenticate permission, or the module needs to be digitally signed. Warning: Null value is eliminated by an aggregate or other SET operation, The statement has been terminated’.

The Solution

It turns out the issue was the the client was using a enterprise wide SQL cluster to host the tfs_ databases. After the Azure DevOps upgrade the DBAs has enabled a trigger based logging system to monitor the databases and this was causing the error.

As soon as this logging was switched off everything worked as expected.

I would not recommend using such a logging tool for any ‘out the box’ database for a product such as TFS/Azure DevOps Server where the DBA team don’t own the database schema’s changes, as these databases will only occur if the product is upgraded

To do a WI update you need to call the REST API

• Using the verb PATCH
• With the Header “Content-Type” set to “application/json-patch+json”
• Include in the Body the current WI update revision (to make sure you are updating the current version)

So the first step is to get the current WI values to find the current revision.

So my update logic was along the lines of

1. Create new WebClient with the Header “Content-Type” set to “application/json-patch+json”
2. Do a Get call to API to get the current work item
3. Build the update payload with my updated fields and the current revision.
4. Do a PATCH call to API using the client created in step 1 to update the current work item

Problem was at Step 4 I got a 400 error. A general error, not too helpful

After much debugging I spotted the issue was that after Step 2. my WebClient’s Headers had changed, I had lost the content type – no idea why.

It all started to work if I recreated my WebClient after Step 2, so something like (in PowrShell)

Function Get-WebClient

{

param  
(

> \[string\]$pat,  
> \[string\]$ContentType = "application/json"

)

> $wc = New-Object System.Net.WebClient  
> $pair = ":${password}"  
> $bytes = \[System.Text.Encoding\]::ASCII.GetBytes($pair)  
> $base64 = \[System.Convert\]::ToBase64String($bytes)  
> $wc.Headers.Add(“Authorization”,"Basic $base64")  
> $wc.Headers\["Content-Type"\] = $ContentType  
> $wc

}

  

function Update-WorkItemTitle {

param

(

$baseUri ,
$teamproject,
$workItemID,
$pat,
$title

)

$wc = Get-WebClient -pat $pat -ContentType “application/json-patch+json”
$uri = “$($baseUri)/$teamproject/_apis/wit/workitems/$($workItemID)?api-version=5.1”

# you can only update a work item if you also pass in the rev, this makes sure you are updating lastest version
$jsondata = $wc.DownloadString($uri) | ConvertFrom-Json

$wc = Get-WebClient -pat $pat -ContentType “application/json-patch+json”

$data = @(
@{
            op    = “test”;
            path  = “/rev”;
            value = $jsondata.Rev
},
@{
            op    = “add”;
            path  = “/fields/System.Title”;
            value = $title
}
) | ConvertTo-Json

$jsondata = $wc.UploadString($uri, “PATCH”, $data) | ConvertFrom-Json
$jsondata

}

The problem is I get into an authentication loop. It happens to be in Chrome, but you might find the same problem in other browsers.

It seems to be a recent issue, maybe related to MFA changes in AAD?

I used to be re-promoted for my ID when I swapped organisations in a browser tab, but not asked for further authentication

However, now the following happens

• I login to an organisation without a problem e.g https://dev.azure.com/someorg using ID, password and MFA
• In the same browser window, when I connect to another organisation e.g. https://dev.azure.com/someotherorg 
• I am asked to pick an account, then there is the MFA challenge, but then go back to the login
• …. and repeat.

The fix is to go in the browser tab to https://dev.azure.com. As you are already authenticated you will be able to sign out, then all is OK, you can login again.

The other options is to make even more use of Chrome People; one ‘person’ per customer, as opposed to my current usage on one ‘person’ per ID

Setup

Folders

Assume you have a Git repo with source for the UI, backend Services and common code in sub folders

/ [root]
     UI
     Services
     Common

Branch Policies

On the Master branch there are a policies of running

• one build for anything in the UI folder/project or common folder/project
• and a different build for anything in the Services folder/project or common folder/project

These build were filtered by path using the filters

/UX; /Common
/Services; /Common

The Issue

I discovered the problem by doing the following

• Create a PR for some work that effects the UI project
• As expected the UI build triggers
• Update the PR with a second commit for the Services code
• The Service build is not triggered

The Solution

The fix was simple it turns out. Remove the spaces from the filter paths so they become

/UX;/Common
/Services;/Common

Once this was done the builds triggered as expected.

Thanks again to the Azure DevOps Product Group for the help

I was trying to use the Regex

content.match(/<PropertyGroup>((.|n)\*)</PropertyGroup>/gmi)

The strange thing was this selection string worked in online Regex testers and in online Javascript IDEs, but failed inside my Node based Azure DevOps Pipeline extension.

After much experimentation I found that the following line worked

content.match(/<PropertyGroup>(\[sS\]\*?)</PropertyGroup>/gmi)

  

Well that a a good few hours of my life I won’t get back. No idea why Node handles the wildcards differently

Done Adding Additional Store  
Error information: "Error: SignerSign() failed." (-2146958839/0x80080209)

From past experience, SignTool errors are usually due to the publisher details in the XML manifest files (in this case unpack the bundle with MakeAppx.exe and look in AppxMetadataAppxBundleManifest.xml, and also check the manifest in the bundled .MSIX files) does not match the subject details for the PFX file being used for signing. 

Or so I thought…..

Turns out you can get this error too if you use the wrong version of the SignTool, but it give no clue to this fact.

So the top tip is …

Make sure you use the SignTool.exe from the same folder as the MakeAppx.exe tool. In  my case in “C:Program Files (x86)Windows Kits10bin10.0.17763.0x64”

Once I did this, after of course updating all the manifest files with the correct publisher details, I was able to sign my bundle as I wanted.