Some random musings on some things that aren’t worth a blog post on their own, but I want to talk about anyway.

How to Check PowerShell Session Has Admin Permissions

A while ago, I shared a piece of PowerShell which is frankly awful, and it does a job that equally as frankly shouldn’t needed to be done. In short, it uninstalls a version of adalsql and installs a specific version so that it works with SSDT. It could be a little more efficient, but at any rate it does the job for now. But recently someone got in touch with me saying that it wasn’t working for them, which is strange as it even works in our ubild pipeline, as well as on my machine cough.

Come to find out that they were not running it in administrator mode. OK simple fix there for them, but I then wondered if it is possible to check if the current PowerShell session is running as administrator or not. Happily it turns out that there is a way, a very simple way.

#Requires -RunAsAdministrator

That’s it. I know it looks a lot like a PowerShell comment, but add that to a script and it will vaidate whether or not the PowerShell session is running with elevated permissions. It’s also treated as a prerequisite, so it is checked prior to executing anything in the script, regardless of where you put it. This even includes within a Function: it’s a gobal property, so if it’s in the script, it will always be checked first. A sample is in th adalsql function what I wrote-

Release as a Branch Policy in VSTS

Earlier this week I released a new PowerShell Module called rib that will kick off a release in a build, with the aim being that you add the build as a branch policy prior to a pull request being added. At the time I stated that this was one possible solution, the other two being “do nothing” and “add release steps to specific pr build”.

There was however another option: contact Microsoft and ask them to add relesaes to branch policies. I dismissed this out of hand because I figured that it would be put on a backlog and never touched. However I hear on the grapevine that it is a feature coming soon, and that if I am lucky enough I might get to have it as a preview feature. This is all very welcoming as rib is a little bit hacky and doesn’t quite work as intended in that you have to have the triggered build as an optional branch policy - because the pull request needs to trigger that build itself to recognise that the build has gone green for that specific pr.

Delete All Branches Except Master

My local repo is inundated with branches I just do not need anymore, and rather than clear out the branches one at a time, I found a neat little cmd to delete all branches but master:

git branch | grep -v "master" | xargs git branch -D

As with runasadmin, very handy, very simple.

Managing Azure Function Keys

I’ve written some PowerShell to get and set Azure Function keys. It works within a VSTS build or release pipeline (providing there is a service principal with contributor credentials set up between VSTS and Azure) and makes use of Azure PowerShell functions and the kudu api. As I understand it, at the moment there is no way to do this via ARM templates, so this can run post-infrastructure deployment. I probably should create this as a PowerShell module as I’ll doubtless add to it. But for now here’s a gist, to give you the, erm, gist of it.

Hopefull this will be added in the ARM Templates, but at the same time if I had the option to create infrastructure through ARM Templates or Azure PowerShell, I’d probably go for Azure PowerShell as it’s less of a pain to manage.