Posted in:

The Azure Functions team recently asked everyone to check the versions of their Function Apps in preparation for the forthcoming 2.0 release.

Please read https://t.co/H6bLvrkWWI if you are still running a pre-release .NET Core build on Azure App Service. #azure #dotnetcore — David Ebbo (@davidebbo) September 1, 2017

Basically you need to check the app settings for each function app and specifically see if the FUNCTIONS_EXTENSION_VERSION setting has any value other than ~1.

Now you can do this fairly easily in the portal, but if, like me, you have a lot of function apps, you might be wondering if there is a way to automate this. And, thanks to the Azure CLI (about which I recently posted a short introductory video), you can do just that.

The main two commands we need are az functionapp list to list all function apps and az functionapp config appsettings list to list all the app settings for a function app.

However, the output of az functionapp list is a very large JSON array as it contains all kinds of information about each application. And I only need to know the name and resource group of each function app.

So I can use the --query switch which allows me to narrow down the output to just the data I want using a powerful query language called JMESPath.

In this case I’ve got a JSON array of objects each of which has a name and resourceGroup property and so I can use the following syntax to trim down the output to just the properties I’m interested in with the following command: az functionapp list --query "[].{Name:name,Group:resourceGroup}"

This produces the following output (showing some function apps I created for my Building Serverless Applications in Azure course):

[
  {
    "Group": "TestDeploy1",
    "Name": "whosplayingdeploy-zq2obg"
  },
  {
    "Group": "WhosPlayingAdmin",
    "Name": "whosplayingadminfuncs"
  },
  {
    "Group": "WhosPlayingFuncs",
    "Name": "whosplayingfuncs"
  }
]

Now I could manually use the values here to get the settings with commands like az functionapp config appsettings list -g WhosPlayingAdmin -n whosplayingadminfuncs, but wouldn’t it be nice if I could automate this and loop through the output?

Well, if we can parse the JSON we can do that, but my bash skills are somewhat limited so I wanted to find an easier way, and we can make the output of az functionapp list even easier to parse by switching to tab separated output with the --output tsv switch.

Now when we run we get the following output:

PS C:\Users\markh> az functionapp list --query "[].{Name:name,Group:resourceGroup}" --output tsv
whosplayingadminfuncs    WhosPlayingAdmin
whosplayingfuncs    WhosPlayingFuncs
whosplayingdeploy-zq2obg    TestDeploy1

By the way, another format you should know about if you’re using the Azure CLI is the --output table format, which gives you a nicely formatted table like this:

PS C:\Users\markh> az functionapp list --query "[].{Name:name,Group:resourceGroup}" --output table
Name                      Group
------------------------  ----------------
whosplayingadminfuncs     WhosPlayingAdmin
whosplayingdeploy-zq2obg  TestDeploy1
whosplayingfuncs          WhosPlayingFuncs

But the tab separated output is what we want. This allows us to parse them into a $name and $resourceGroup variable and get the app settings for that app with the az functionapp config appsettings list -n $name -g $resourceGroup command.

But when we run this we have the same problem: too much output. And the --query flag again comes to our rescue. We can use it just to narrow it down to the setting we are interested in:

PS C:\Users\markh> az functionapp config appsettings list -n $name -g $resourceGroup --query "[?name=='FUNCTIONS_EXTENSION_VERSION']"
[
  {
    "name": "FUNCTIONS_EXTENSION_VERSION",
    "slotSetting": false,
    "value": "~1"
  }
]

And we can even pick out just the value of that setting with another change to the JMESPath query and choosing tab separated output:

PS C:\Users\markh> az functionapp config appsettings list -n $name -g $resourceGroup --query "[?name=='FUNCTIONS_EXTENSION_VERSION'].value" --output tsv
~1

So we have all the bits in place for automating checking the versions of all the function apps in our subscription. I decided to do this with the Windows Subsystem for Linux (WSL or Bash on Windows), since the Azure CLI is designed to be used from bash (although you are perfectly free to use it from PowerShell too if you prefer). Instructions for installing the WSL can be found here and you then use apt-get to install the CLI as described here.

With that in place, we can write a simple bash script to loop through all the function apps, query for the value of the FUNCTIONS_EXTENSION_VERSION app setting and print them out. My bash skills are very basic, so do let me know in the comments if there are better ways to accomplish this:

#!/bin/bash
az functionapp list --query "[].{Name: name,Group: resourceGroup}" -o tsv |
while read -r name resourceGroup; do
   version=$(az functionapp config appsettings list \
      -n $name -g $resourceGroup \
      --query "[?name=='FUNCTIONS_EXTENSION_VERSION'].value" -o tsv)
   printf 'N:%s R:%s V:%s\n' "$name" "$resourceGroup" "$version"
done

When we run this in our bash shell, we see the following output for this subscription. Looks like all my settings had the right value anyway:

mheath@DESKTOP-R7KVMG5:~$ ./funcappversion.sh
N:whosplayingfuncs R:WhosPlayingFuncs V:~1
N:whosplayingdeploy-zq2obg R:TestDeploy1 V:~1
N:whosplayingadminfuncs R:WhosPlayingAdmin V:~1

But my point in sharing this post wasn’t really to show you how to check function app versions, but to highlight just how powerful using the --query switch and JMESPath query language along with the  --output tsv switch to get tab separated output. The JMESPath website has plenty of great examples and I found it surprisingly quick to learn the syntax I needed for my queries.

Want to learn more about how easy it is to get up and running with Azure Functions? Be sure to check out my Pluralsight courses Azure Functions Fundamentals and Microsoft Azure Developer: Create Serverless Functions

Comments

Comment by K117

Great article, easier than Microsoft Docs!

K117
Comment by Nazik Huq

Concur with previous poster. This article was thoughtfully written.

Nazik Huq