Issue Many development tools rely on the fact that git.exe is installed to perform source control operations e.g. VSCode. However, a common problem I have seen is that security settings on many corporate Windows devices do not allow the installation of git CLI using an MSI file by the user. VSCode is an approved application, or installed as a user application as opposed to a system one, so is available but limited by it’s lack of source control features. ...

Background I have recently hit a problem whilst developing some training material on Single Sign on (SSO) in GitHub Enterprise. This training is to be delivered in a training instance of GHE that is configured to use a training instance of Azure Entra ID as the SAML identity provider. To make my life easier, so I am not logging in and out of my work and test Azure Entra ID directories, I have been using profiles in my Chromium based Edge browser. This means I have two copies of Edge running, one for my ‘real’ work directory and the other for the training directory. ...

Background On some projects we use Jeremy Long’s DependencyCheck tool, via the Azure DevOps task, to scan our code for known vulnerabilities. This tool uses the National Vulnerability Database (NVD) to get its data. This data is downloaded on demand from the NVD site but the DependencyCheck tool. Since the recent API changes on the NVD site, as supported by DependencyCheck 9.0.x, the downloading of the current vulnerability data has slowed from about 3 minutes to around 15 minutes, even with a valid NVD API Key. So effectively slowing all our pipeline builds by 15 minutes, a very significant change if the rest of the build only takes a few seconds! ...

The Problem I have been using Packer to generate our Azure DevOps Build agent VHD images for a while now, but when I came to regenerate them this time I hit a problem. As I have documented previously, our process is that we update our fork of the Microsoft repository and then merge the newest changes into our long lived branch that contains our customisations. I then use Packer to generate a new generalised VHD which has all the same features as the Microsoft hosted agents. I then use this VHD to create our new Hyper-V based self hosted Azure DevOps agent VMs using Lability. ...

In advance of my upcoming Black Marble Webinar on the 18th October entitled ‘Practical DevOps in the Enterprise’, I have written a whitepaper of the same name. You can find the whitepaper on LinkedIn and register for this, and other free Black Marble webinars and in-person events, via the Black Marble website.

The Problem 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. ...

The Issue If you are using Azure Scale Set based Azure DevOps Agent Pools (VMSS) to provide dynamically scalable agent pools, unlike with self hosted agent pools, there is no capabilities tab for the individual agents. My understanding is that this UX design choice was made as the capabilities of all the agents in a VMSS pool are identical, as they are the same disk image, so why show the same data multiple times. ...

Background I have recently been looking at getting Snipe-IT running on Azure using a Docker container. Though the documentation for this project is good, the detail for the Azure setup is a little lacking. So I thought I would document the steps and Rik Hepworth took to get it working. Notes: This is a simple configuration to get it working, it can obviously get a lot more complex with the setup of VNETs etc. This post documents the manual process, best practice and the next step will be to get it all automated with BICEP/ARM template - For an example of this see this GiST Create an Azure MySQL PaaS instance Open the Azure Portal Create a new ‘Azure Database for MySQL flexible server’ in a new resource group Provide a name for the instance Set your region Workload Type - for this test I use the lowest ‘for development or hobby projects’ Set the MySQL username and password For networking pick ‘allow public access’ and ‘allow public access for any Azure service’ You can add your Client IP address to the firewall rules if you want to be able to connect to the DB from your local machine, but this is not essential. I had enabled this to do some testing with a locally hosted Docker instance. ...

The Problem Recently had an issue on a project that had been paused for a few months. When we restarted the project we found that the SonarCloud PR analysis, running via an Azure DevOps YAML pipeline, was failing with a 404 error. The strange thing was that the same pipeline running analysis of the main trunk or the branch the PR related to worked without error. The Solution The issue was fixed by regenerating the SonarCloud PAT that was registered in the Azure DevOps project’s Service Connection. ...

The Problem Recently an Azure DevOps Pipeline for a .NET 6 based Azure Functions started to fail on some of our self-hosted build agents with the error ##[error]C:\Users\Administrator\.nuget\packages\microsoft.azure.webjobs.script.extensionsmetadatagenerator\4.0.1\build\Microsoft.Azure.WebJobs.Script.ExtensionsMetadataGenerator.targets(37,5): Error : Metadata generation failed. Exit code: '-2147450750' Error: 'Failed to load the dll from [C:\hostedtoolcache\windows\dotnet\shared\Microsoft.NETCore.App\3.1.32\hostpolicy.dll], HRESULT: 0x800700C1An error occurred while loading required library hostpolicy.dll from [C:\hostedtoolcache\windows\dotnet\shared\Microsoft.NETCore.App\3.1.32]' The pipeline it self was simple, just repeating the steps a developer would use locally - task: UseDotNet@2 displayName: "Use .NET 6" inputs: packageType: sdk version: 6.x performMultiLevelLookup: true - task: DotNetCoreCLI@2 displayName: "dotnet restore" inputs: command: restore projects: "$(Build.SourcesDirectory)/src/Api.sln" feedsToUse: "select" vstsFeed: "aaa33827-92e2-45a0-924a-925b0d6344677" # organisation-level feed - task: DotNetCoreCLI@2 displayName: ".NET Build" inputs: command: "build" arguments: > --configuration ${{ parameters.buildConfiguration }} --no-restore projects: "$(Build.SourcesDirectory)/src/Api.sln" The Cause The issue was that the dotnet build was picking up a .NET 3.1 version of the hostpolicy.dll from the cache. This was even though the pipeline was set to use .NET 6, and I could see both .NET 3.1 and .NET 6 SDKs in the cache folder. ...