DEV Community: Frits Becker

Auto update version

Frits Becker — Mon, 19 May 2025 05:46:23 +0000

As developers, we do not want to waste time on releases, and one of the challenges with an automatic release is updating the version number.

Conventional Commits

At multiple companies I have introduced the conventional commits website. This allows us to easily add the type of change in our commit title.

If every developer uses these conventions, you can automate versioning in the pipeline, and that is what I did about two years ago. I will show you how.

First of all, I have to admit that I am not a PowerShell guru, so feel free to improve the scripts if this post helped you.

Now lets start with all the steps we need to take and what better way then using an example pipeline.

Patch number logic

We set the default name of the pipeline to $(date:yyyyMMdd)$(rev:rr), so we can use this as the patch number. This gives us a couple of advantages:

No need for +1 or reset to 0 logic
We always know when a version is released

Now there are some restrictions to this, at least if you create a NuGet package:

Version parts in NuGet are integers, so the max version is 2147483647
Limit is 99 releases a day
This logic will fail from the year 2148; this will be the new Y2K bug!

# 2147483647
# yyyyMMddrr
name: $(date:yyyyMMdd)$(rev:rr)

variables:
  system_accesstoken: $(System.AccessToken)
  projectName: 'name'
  isMaster: $[eq(variables['Build.SourceBranch'], 'refs/heads/master')]

trigger:
  - master

Reuse scripts

After writing and testing the scripts (details later in the blog) we put the scripts in another repository, so they are reusable

resources:
  repositories:
    - repository: repoName
      type: git
      name: TeamProjectName/repoName

Nobody is perfect

Sometimes a (new) developer forgets to add the convention. So we added two extra parameters to set the type of release when we run a pipeline manually.

parameters:
  - name: buildConfiguration
    type: string
    default: 'Release'
version
  - name: releaseNewVersion
    type: boolean
    default: false
  - name: newVersionType
    type: string
    default: 'patch'
    values:
      - patch
      - minor
      - major

This is how it looks when manually starting a run

verion tag in git

Our scripts will write the new version as a tag to Git. This means the pipeline needs permission to push to the repository.

steps:
  - checkout: self
    displayName: "Git checkout with allow scripts to access the system token for pushing"
    persistCredentials: true
    clean: true
    fetchDepth: 0

flow of scripts

Here you can see all the scripts we built and how we call them in the pipeline.

  - template: scriptsFolderName/set-latest-version-in-variables.yml@repoName
  - template: scriptsFolderName/update-version-variables.yml@repoName
    parameters:
      overruleNewVersion: ${{ parameters.ReleaseNewVersion }}
      newVersionType: ${{ parameters.newVersionType }}
  - template: scriptsFolderName/create-git-tag.yml@repoName
  - template: scriptsFolderName/update-version-in-project-file.yml@repoName
    parameters:
      buildConfiguration: ${{ parameters.buildConfiguration }}
  - template: scriptsFolderName/default-build.yml@repoName
    parameters:
      buildConfiguration: ${{ parameters.buildConfiguration }}

  - template: scriptsFolderName/push-new-version.yml@repoName
    parameters:
      buildConfiguration: ${{ parameters.buildConfiguration }}

  - powershell: |
      $newVersion = "$($(Major)).$($(Minor)).$($(Patch))"
      Write-Host "##vso[build.updatebuildnumber]$newVersion"
    displayName: 'Rename pipeline to new version'
    condition: and(succeeded(), eq(variables.isRelease, 'true'))

Setting the Latest Version

To set the latest version, we get the latest tag. When no tag is available, we use version 0.0.0.

When you implement this script but want to start with a higher version, just create that tag if it is not already available.

After setting the full version, we split it up into major, minor, and patch variables that we can update later in the pipeline.

#set-latest-version-in-variables.yml
steps:
- powershell: |
    $latestVersion = git describe --tags --abbrev=0 2>$null
    if ($latestVersion) {
      echo "Current version: $($latestVersion)"
    } else {
      $latestVersion = "0.0.0"
      echo "No tag was found. Using version 0.0.0 as a base."
    }

    $versionArray = $latestVersion -split "\."

    $major = [int]$versionArray[0]
    $minor = [int]$versionArray[1]
    $patch = [int]$versionArray[2]

    Write-Host "##vso[task.setvariable variable=Major]$major"
    Write-Host "##vso[task.setvariable variable=Minor]$minor"
    Write-Host "##vso[task.setvariable variable=Patch]$patch"
  displayName: 'Get latest version and set variables'
  condition: and(succeeded(), eq(variables.isMaster, 'true'))

Incrementing the Version Number

The normal flow will be that the run was triggered automatically and the convention was used, which means that the commit title starts with:

fix = patch
feat = minor
anyType! = major

We do this with regex and also get other parts of the commit message. Who knows, maybe we can use them in the future. Some examples of how the regex will return the results.

After this, we just check the type of change and update the corresponding version type, where the patch will always be updated.

We added some extra checks for the manual run part that overrules the default logic.

#update-version-variables.yml
parameters:
  overruleNewVersion: false
  newVersionType: ''

steps:
- powershell: |
    $latestCommitTitle = git log -n 1 --pretty=format:"%s"

    #Normalize title
    $pattern = "^merged pr \d+:\s*(.*)"
    $normalizedTitle = $latestCommitTitle.ToLower()
    if($latestCommitTitle.ToLower() -match $pattern) {
      $normalizedTitle = $matches[1]
    }      

    $pattern = "(?<type>\w+)(?<scope>(?:\([^()\r\n]*\)|\()?(?<breaking>!)?)(?<subject>:.*)?"
    $normalizedTitle -match $pattern
    echo "type: $($matches["type"])"
    echo "scope: $($matches["scope"])"
    echo "breaking: $($matches["breaking"])"
    echo "subject: $($matches["subject"])"

    $major = [int]$(Major)
    $minor = [int]$(Minor)
    $patch = $(Patch)

    $changed = $false
    if('${{ parameters.overruleNewVersion }}' -eq "true") {
      echo '${{ parameters.newVersionType }}'
      $changed = $true

      if('${{ parameters.newVersionType }}' -eq "major") {
        echo "breaking change" 
        $major += 1
        $minor = 0
      }
      elseif('${{ parameters.newVersionType }}' -eq "minor"){
        echo "minor change"
        $minor += 1
      }
      else{
        echo "patch change"
      }
    }
    else {    
      if($matches["breaking"] -ne $null) {
        echo "breaking change" 
        $major += 1
        $minor = 0
        $changed = $true
      }
      elseif($matches["type"] -eq "feat"){
        echo "minor change"
        $minor += 1
        $changed = $true
      }
      elseif($matches["type"] -eq "fix"){
        echo "patch change"
        $changed = $true
      }
    }

    echo "Changed: $($changed)"
    if($changed) {
    Write-Host "##vso[task.setvariable variable=Major]$major"
    Write-Host "##vso[task.setvariable variable=Minor]$minor"
    Write-Host "##vso[task.setvariable variable=Patch]$(Build.BuildNumber)"
    Write-Host "##vso[task.setvariable variable=IsRelease]true"
    }
  displayName: 'Check change type and update version'
  condition: and(succeeded(), eq(variables.isMaster, 'true'))

Creating the Git Tag

When there was a change that needed a release, the isRelease variable will be set to true in the last script, and when it is, we just create a new Git tag.

This will only work if you set the Git permission in the pipeline with persistCredentials: true

#create-git-tag.yml
steps:
- powershell: |
    git tag "$($(Major)).$($(Minor)).$($(Patch))"
  displayName: 'Create git tag'
  condition: and(succeeded(), eq(variables.IsRelease, 'true'))

Optional: Updating project file

We develop libraries/NuGet packages in .NET, so the last step for us will be an update to the .csproj file. This will ensure that when we build, the version of the NuGet package will be correct.

As I have written earlier, NuGet uses an integer per version type. But if we look deeper, we find something interesting. The type is different per tag:

Packageversion: int32
version: int16 = 32.767

#update-version-in-project-file.yml
parameters:
  projectName: ''

steps:
- powershell: |
    $newVersionTag = git describe --tags --abbrev=0
    echo "New version tag: $($newVersionTag)"

    $projectName = '$(projectName)'
    $pattern = '^(.*?(<PackageVersion>|<Version>).*?)([0-9].[0-9]{1,2}.)(([0-9]{1,2})(-rc([0-9]{2}))?)(.*?)$'
    $path = if (Test-Path -Path $projectName) {'{0}\*' -f $projectName } else { '*' }
    $ProjectFileName = '{0}.csproj' -f $projectName
    $ProjectFiles = Get-ChildItem -Path $path -Include $ProjectFileName -Recurse

    foreach ($file in $ProjectFiles)
    {
        echo "file: $($file)"
        echo "file path $($file.PSPath)"
        (Get-Content $file.PSPath) | ForEach-Object{
            if($_ -match $pattern){
                '{0}{1}{2}' -f $matches[1],$newVersionTag,$matches[8]
            } else {
                # Output line as is
                $_
            }
        } | Set-Content $file.PSPath
    }
  displayName: 'Update version in project file'
  condition: and(succeeded(), eq(variables.IsRelease, 'true'))

I hope this helps you guys with automating your versioning process and streamlining your releases. Feel free to reach out if you have any questions or need further assistance. Happy coding! 😊

Streaming Azure DevOps auditlogs to azure monitor

Frits Becker — Sat, 19 Apr 2025 12:06:45 +0000

Introduction

As a platform team, one of the platforms we manage is Azure DevOps. The users and teams using the platform keep growing, and with this growth, we need to implement more tools to maintain control and security without requiring additional time.

One of the tasks is monitoring the audit logs. Unfortunately, the user interface within Azure DevOps is not user-friendly. The only filter available is a time range, but when you want to use the logs, you need to filter by team project, organization, or even the user. Another important tool that is missing are alerts.

Improving monitoring

To help us improve the monitoring of these logs, we set up a stream to a log analytics workspace in Azure. However, even though we used the microsoft learn page "Create audit streaming", this did not work out of the box, and we received the error message "Forbidden".

This meant that the log analytics resource returned an HTTP 403, even though we set it up as publicly available. After some research, we found out that the feature "disableLocalAuth" was set to true, which block connections with agent key's.

After setting this to false, configuring the stream worked! An example of Bicep code to deploy the log analytics workspace is:

module logWorkspaceAdo 'br/public:avm/res/operational-insights/workspace:0.11.0' = {
  params: {
    name: 'log-${resourceName}-001'
    location: location
    publicNetworkAccessForIngestion: 'Enabled'
    publicNetworkAccessForQuery: 'Enabled'
    features: {disableLocalAuth: false}
    tags: tags
  }
}

After this, we can easily implement workbooks, alerts, or create a report in Power BI.

I hope this helps you set up the stream if you had the same problem as me.

Improving security

Even though this work, I still have some questions around security. The issues that I have are:

Public network access
Using a key to connect

With all other connections, we go through our own private network and where possible we try to do the authentication with federated credentials end managed identities. And if we really need the allow public network, we use serviceTags for the microsoft service, but I did not see this possibility in the Log Analytics Workspace.

If you know how to improve security for this setup, please let me know.

Azure functions throw errors when diagnostic settings are enabled for the storage account.

Frits Becker — Sat, 19 Apr 2025 09:00:00 +0000

Issue is fixed!!!

The issue from this blog is fixed with v4.839.500, v4.639.500 and v4.1039.500. Check your logs for the host SDK and when it is updated, we should be able to remove whatever workaround is chosen.

Introduction

Recently, we added a mandatory diagnostic setting to the blob service in our storage account module. This sends audit logs to a central log analytics workspace.

resource diagnosticSettings 'Microsoft.Insights/diagnosticSettings@2021-05-01-preview' = {
  scope: blobService
  name: 'auditlogs'
  properties: {
    logs: [
      {
        enabled: true
        categoryGroup: 'audit'
      }
    ]
    workspaceId: auditWorkspace.id
  }
}

When Issues Arise

When updating the storage account module in the infra repository of a DevOps team, errors began to appear in their application insights. Errors like:

Error occurred when attempting to purge previous diagnostic event versions.
Unable to get table reference or create table. Aborting write operation.

All of them had Category "Microsoft.Azure.WebJobs.Script.WebHost.Diagnostics.DiagnosticEventTableStorageRepository"

Quest for answers

We had no idea why this happened, so we began our quest and quickly found multiple issues on the "Azure Functions Host" GitHub repository.

Luckily this bug was fixed in october last year with the PR 'Added support for identity-based connections to Diagnostic Events' and released on December 19th in version 4.837.0.

We used a managed identity to assign the correct roles to the functions on the storage account. Upon checking the error logs, we discovered that we were using SDK version 4.1038.300.25164. But the problem was that downgrading is not possible. we tried to change FUNCTIONS_EXTENSION_VERSION, but it does not work as expected. So we had to find out why this error is back and how to fix this.

We found out that MSFT updated to version 4.1038.300.25164 on 4/16/2025. Before that, the logs show version 4.1037.1.23605, where there were no problems. For now, we have to wait for a fix, but we can find 2 issues in the Azure Function Host GitHub with some temporary changes to avoid/ignore the errors.

Temporary solutions

Here are some options that are given in the issues:

For the time being, you can add a log filter for Microsoft.Azure.WebJobs.Script.WebHost.Diagnostics.DiagnosticEventTableStorageRepository to host.json and filter out logs.
You can also disable this feature via an app setting: AzureWebJobsFeatureFlags=DisableDiagnosticEventLogging.

The PR we are waiting for to be released right now is PR 10996.

Managed identities

Frits Becker — Fri, 21 Mar 2025 15:55:32 +0000

In my work, I still see developers struggling with authentication and authorization, that’s why I want to create some posts to explain how simple this can be in the azure cloud, within the same tenant.

We can use managed identities and they have multiple advantages.

no secrets
automatic lifecycle management with a system managed identity
almost no knowledge needed of Entra ID
easy to understand RBAC roles

This post will show, how you can use managed identities to connect to a azure service called key vault from a web app. One of the most basic things most developers will have to deal with.

Before showing the code, I want to give a shout out to the public bicep repository, this repo is perfect for learning bicep and quickly implementing IaC.

When creating the infra, we need 3 modules:
Optional: Create a user managed identity that will get the role assignments

module managedIdentity 'br/public:avm/res/managed-identity/user-assigned-identity:0.4.0' = {
  name: 'name'
  params: {
    ...
  }
}

Create the key vault

Check https://github.com/Azure/bicep-registry-modules/blob/main/avm/res/key-vault/vault/README.md#parameter-roleassignments for more roles

module vault 'br/public:avm/res/key-vault/vault:0.12.1' = {
  name: 'name'
  params: {
    roleAssignments: [
      { // Give managed identity a role to read the secrets
        principalId: managedIdentity.outputs.principalId
        principalType: 'ServicePrincipal'
        roleDefinitionIdOrName: 'Key Vault Secrets User'
      }
    ]
    ...
  }
}

Create a webapp

module App 'br/public:avm/res/web/site:0.15.1' = {
  name: 'name'
  params: {
    kind: 'app'
    managedIdentities: { //assigning a managed identity to the web app to access the key vault secrets
      systemAssigned: false //set to true and remove line below if you only want this
      userAssignedResourceIds: [managedIdentity.outputs.resourceId]
    }
    ...
  }
}

And a simple implementation within the .net web app

Check https://learn.microsoft.com/en-us/dotnet/api/overview/azure/identity-readme for more information about the authentication types and flows.


using Azure.Identity;

var credentials = new ChainedTokenCredential(!builder.Environment.IsDevelopment() 
    ? new ManagedIdentityCredential(userManagedIdentityClientId) 
    : new VisualStudioCredential(), new AzureCliCredential(), new InteractiveBrowserCredential());

builder.Configuration.AddAzureKeyVault(new Uri($"https://{builder.Configuration["KeyVaultName"]}.vault.azure.net/"), credentials);

After this, you only need to deploy the infra and your web app and everything should work in the cloud!

For testing locally, you need to add an extra role assignment to the keyvault, for your personal identity or a group that you are in.

The bicep for keyvault would look something like this

module vault 'br/public:avm/res/key-vault/vault:0.12.1' = {
  name: 'name'
  params: {
    roleAssignments: [
      { // Give managed identity a role to read the secrets
        principalId: managedIdentity.outputs.principalId
        principalType: 'ServicePrincipal'
        roleDefinitionIdOrName: 'Key Vault Secrets User'
      }
      { // Give dev group a role to read the secrets for local testing
        principalId: 'GUID'
        principalType: 'Group'
        roleDefinitionIdOrName: 'Key Vault Secrets User'
      }
    ]
    ...
  }
}

I hope this helps my fellow developers to easily use azure resources in your applications in a safe way.