TechTips

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

Around a year ago I posted on ‘Social Media Posts after Migrating from WordPress to Hugo Static Pages’. Recently I have found that the Twitter functionality in my Logic App was failing. Turns out this was due to the changes in the Twitter Free API, with them moving from V1 to V2 which requires OAuth authentication as opposed to a Bearer token. In essence the core of the problem is that the built-in Logic Apps Twitter Connector only supports the V1 Twitter API. So the only option was to create my own custom solution. ...