PowerShell: Folder Diff

With a new git repo, I after push the source code and then re-pull to a new local repo. To verify the .gitignore is correct, I diff the original folder containing the source code against the git clone just created. The following PowerShell is what I use to dif the folders:

param(

    [Parameter(Mandatory=$true)]

    [string] $folderSource,

    [Parameter(Mandatory=$true)]

    [string] $folderDestination

)

Set-StrictMode -Version 3.0

$ErrorActionPreference = 'Stop'

Set-PSDebug -Off

# Set-PSDebug -Trace 1

[int] $exitCodeSuccess = 0

[int] $exitCodeError = 1

[int] $exitCode = $exitCodeSuccess

function Get-RelativeFilePaths {

    param(

        [Parameter(Mandatory=$true)]

        [string] $folderPath

    )

    [string] $resolvedFolderPath = 

        (Resolve-Path -Path $folderPath -ErrorAction Stop).Path + '\'

    return (

        Get-ChildItem `

            -Path $folderPath `

            -Recurse `

            -File `

            -ErrorAction Stop).

            FullName.

                Replace($resolvedFolderPath, '')

}

try {

    [string[]] $sourceFiles = `

                 Get-RelativeFilePaths $folderSource

    [string[]] $destinationFiles = `

                 Get-RelativeFilePaths $folderDestination

    

    Compare-Object `

        -ReferenceObject $sourceFiles `

        -DifferenceObject $destinationFiles `

        -ErrorAction Stop    

}

catch {

    [System.Management.Automation.ErrorRecord] $errorRecord = $PSItem

    $exitCode = $exitCodeError

    Write-Host $errorRecord

    Write-Host `

        "Exception Message: $($errorRecord.Exception.Message), " + `

        "Stacktrace: $($errorRecord.Exception.StackTrace)"

}

return $exitCode

The launch.json is as followings when running from Visual Studio Code:

{

    "version": "0.2.0",

    "configurations": [

        {

            "name": "Compare-Folders",

            "type": "PowerShell",

            "request": "launch",

            "script": "${workspaceRoot}/Compare-Folders.ps1",

            "cwd": "${workspaceRoot}",

            "args": [

                "-FolderSource",

                <source folder>,

                "-FolderDestination",

                <destination folder>

            ]

        }

    ]

}

Visual Studio Code: Error Generation Bicep Template from Existing Azure Resource

The latest version of Microsoft's Bicep Extension (v0.26.54) for Visual Studio Code has a new behavior that causes an error message to be generated under certain circumstances. The Bicep Extension was covered in a blog post eighteen months ago (November 26, 2022: Azure: Generate a Bicep Template from an Existing Azure Resource using Visual Studio Code) and the manifesting of the following error message is a newish behavior in the extension:

Caught exception fetching resource: The ChainedTokenCredential failed to retrieve a token from the included credentials. - Please run 'az login' to set up account - Please run 'Connect-AzAccount' to set up account.

The error message above is generated while attempting to use the command, Bicep: Insert Resource (F1 displays the command palette or CTRL-SHIFT-P on Windows or CMD-SHIFT-P on Mac):

The error message is generated when a valid resource ID is entered for the Bicep: Insert Resource command and OK is clicked on in order to extract the Bicep template for an existing resource. The error message (see below) suggests a solution, logging in using Azure CLI (az login) or PowerShell (Connect-AzAccount):

At the time the error is generated, the Visual Studio Code Azure Extension is logged into a valid Azure Subscription:

Visual Studio Code's accounts show that the correct Microsoft account is logged in:

The solution is to log in to Azure via the Visual Studio Code Terminal window (displayed using CTRL-`):

There Terminal window above is PowerShell, so Azure will be logged into using Connect-AzAccount (note: Azure CLI's az login could also have been used):

Once the Terminal window is used to log in to, Azure the Bicep: Insert Resource command will run successfully meaning a Bicep template will be extracted from an existing Azure resource.

Visual Studio Code: Azure Extension Pack error "Expected value to be neither null nor undefined"

This post presents a solution to the following error displayed in Visual Studio Code when using the Azure Tools Extension Pack:

Internal error: Expected value to be neither null nor undefined: resourceGroup for grouping item

The Azure Tools Extension Pack (Azure Tools) is critical to Azure developers who use Visual Studio Code (see the A below):

When signed in to a subscription, the Azure Tools Extension displays Azure resources by default, grouped by resource group. For some subscriptions (not all) the following error is displayed by Visual Studio Code when group by is set to "Group by Resource Group":

The fix to this issue is to click on the group by icon:

This displays the following context menu:

From the context menu, select the menu item "Group by Resource Type." This has change causes the error to no longer be raised. For subscriptions experiencing this error, there seems to be no way to select the Group By menu item "Group by Resource Group" without generating an error.

Azure DevOps: Requiring Pull Requests to be Associated with a Work Item

Whether following Git Flow, GitHub Flow, GitLab Flow or Trunk-based Development certain policies are standard to source code best practices. For example. each Pull Request (PR) must be associated with a single task/story/epic (a linked work item). This post discusses Azure DevOps support for this feature.

For a given ADO Git repo, branch policies (such a requiring a PR to be linked to a work item) are set per-branch. There is no way to assign such policies to multiple branches. In order to set a branch's policies, navigate to a Repo's branches tab:

For a branch whose policy is to be set, click on the three dots to show the context menu shown below: 

From the context menu, select Branch policies. From the Branch Policies tab click on Check for linked work items:

Under Check for linked work items, insure the Required radio button is selected:

Git Branch Strategies

Requiring "check for linked work items" is set per-branch. Which branches this will be set for depends on the git branch strategy adopted.

Git Branch Strategy: Git Flow

For the Git Flow branching strategy the following branches would require a linked work item:

• Main/Master
• Develop
• Feature
• Release
• Hotfix

Git Branch Strategy: GitHub Flow

For the GitHub Flow branching strategy the following branches would require a linked work item:

• Main/Master
• Feature

Git Branch Strategy: GitLab Flow

For the GitLab Flow branching strategy the following branches would require a linked work item:

• Main/Master
• Feature
• Pre-Production
• Production

Git Branch Strategy: Trunk-based Development

For the Trunk-based Development branching strategy the following branches would require a linked work item:

• Main/Master
• Trunk
• Feature

Azure/PowerShell: Geolocating Storage Account White Listed IP Addresses

On a project, we had provided access to to an Azure Storage account by adding permitted IP addresses to the firewall (white listed IPs). These settings can be found via https://portal.azure.com/ by navigating to the storage account and selecting Network under "Security + networking":

I was tasked with writing a script to list all the white listed IP addresses and display there geographic location. The http://ip-api.com returns (for free) the geo data associated with an IP address. This service is free for no-commercial use:

The PowerShell script to return this information takes two required parameters:

• $resourceGroupName: resource group name associated with storage account
• $storageAccountName: storage account name whose white listed IPs will be returned

The script in its entirety is as follows:

param(

    [Parameter(Mandatory=$true)]

    [string] $resourceGroupName,

    [Parameter(Mandatory=$true)]

    [string] $storageAccountName

)

Set-StrictMode -Version 3.0

$ErrorActionPreference = 'Stop'

Set-PSDebug -Off

#Set-PSDebug -Trace 1

# FYI: Import-Module Az.Storage -ErrorAction Stop

[int] $exitCodeSuccess = 0

[int] $exitCodeError = 1

[int] $exitCode = $exitCodeSuccess

try {

    Connect-AzAccount -ErrorAction Stop | Out-Null

    [Microsoft.Azure.Commands.Management.Storage.Models.PSNetworkRuleSet] $networkRuleSet = 

        Get-AzStorageAccountNetworkRuleSet `

            -ResourceGroupName $resourceGroupName `

            -Name $storageAccountName `

            -ErrorAction Stop

    [Microsoft.Azure.Commands.Management.Storage.Models.PSIpRule[]] $ipRules = 

        $networkRuleSet.IpRules

    $ipRules | ForEach-Object { 

        [string] $ip = $_.IPAddressOrRange

        [PSCustomObject] $response = Invoke-RestMethod `

                        -Uri "http://ip-api.com/json/$ip" `

                        -ErrorAction Stop

        Write-Output ( `

            "$ip, $($response.isp), $($response.city), " +

            "$($response.regionName), $($response.zip), " +

            "$($response.country)")

    } -ErrorAction Stop

}

catch {

  [System.Management.Automation.ErrorRecord] $errorRecord = $PSItem

  $exitCode = $exitCodeError

  Write-Host $errorRecord

  Write-Host "Exception Message: " + ` 

    $($errorRecord.Exception.Message)," +` 

    Stacktrace: $($errorRecord.Exception.StackTrace)"

}

return $exitCode

The Get-AzStorageAccountNetworkRuleSet cmdlet is described as follows (see Get-AzStorageAccountNetworkRuleSet):

IP Ranges versus Individual IP Addresses

The following $ipRules variable returns IP addresses and range of IP address:

[Microsoft.Azure.Commands.Management.Storage.Models.PSNetworkRuleSet] $networkRuleSet = 

        Get-AzStorageAccountNetworkRuleSet `

            -ResourceGroupName $resourceGroupName `

            -Name $storageAccountName `

            -ErrorAction Stop

    [Microsoft.Azure.Commands.Management.Storage.Models.PSIpRule[]] $ipRules = 

        $networkRuleSet.IpRules

In the code sample above it is assumed $ipRules contains only IP addresses otherwise the following code where the http://ip-api.com/json service is invoked would not work as the expected parameter is an IP address not an IP address range:

        [string] $ip = $_.IPAddressOrRange

        [PSCustomObject] $response = Invoke-RestMethod `

                        -Uri "http://ip-api.com/json/$ip" `

                        -ErrorAction Stop

Azure: Virtual Machines that support WSL

Azure Nested Virtualization Capable VMs

In order to run WSL and potentially Docker on an Azure Virtual Machine (VM) a VM's SKU Family must be hyper-threaded and be capable of running nested virtualization. The following link from Microsoft Learning, Azure compute unit (ACU), demarcates in a table all nested virtualization capable VMs by three asterisks: 

Azure WSL Capable VM Types

The Azure VM that are capable of supported WSL (a.k.a. capable of running nested virtualization) are as follow from Microsoft's article, Azure compute unit (ACU), provided that the vCPU: Core column contains three asterisks:

The following include several other VM types on which WSL can be installed:

Azure Subscription may not include WSL Capable VM Types

Be aware the not ever Microsoft subscription supports such Virtual Machines. For example the subscription that comes in a Visual Studio Subscription (the $150 free monthly Azure credit) might contain no virtual machines types that are nested virtualization capable.

Docker: Fails on Windows Immediately After Install

Recently I installed Docker on a Windows 11 Pro laptop. Immediately after install I attempted to run a Docker image containing PowerShell. This image was run by invoking the following command from a PowerShell console:

docker run -it mcr.microsoft.com/powershell

The error returned by this command was:

docker: error during connect: this error may indicate that the docker daemon is not running: Post "http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.24/containers/create": open //./pipe/docker_engine: The system cannot find the file specified.

See 'docker run --help'.

The error above is clear "this error may indicate that the docker daemon is not running" which means I had forgotten to run Docker Desktop. Windows 11 Pro and Windows 10 Pro require Docket Desktop in order to run the Docker Engine.

I started Docker Desktop, reran the docker run command, and received a subsequent error:

docker: request returned Internal Server Error for API route and version http://%2F%2F.%2Fpipe%2Fdocker_engine/v1.24/containers/create, check if the server supports the requested API version.

See 'docker run --help'.

As engineers we all have our Home Simpson, "Duh" moments. When I actually looked at Docker Desktop, I saw the following:

I had failed to Accept the terms of service screen so the Docker Engine was not started. The lesson learned: After installing Docker Desktop on on Windows 10 Pro or Windows 11 Pro, run Docker Desktop and click on the Accept button.

I am very explicit about using Windows 11 Pro or previously Windows 10 Pro. The reason for this is that Windows 10 and Windows 11 can run Linux containers only with Docker installed. In order to run Windows containers, Windows 10 Pro or Windows 11 Pro is required.

In a previous blog, I noted a change I'd made (indirectly) to Docker's installation instructions for Docker Desktop on Windows, Install Docker Desktop on Windows. I created a PR in the documentation noting the importance of Windows Pro and the Docker documentation team added the following warning to their installation guide