Down the rabbit hole – Azure function environment variables

The other day I was working on a solution that used the environment variable HOME to determine whether or not it is running locally or deployed. When the HOME was not empty, the path to a file was built with the HOME + \sites\wwwroot\ + relative path.

public static string getFilename(string basename)
{

	var filename = "";
	var home = getEnvironmentVariable("HOME");
	if (home.Length == 0)
	{
		filename = "../../../" + basename;
	}
	else
	{
		filename = home + "\\site\\wwwroot\\" + basename;
	}
	return filename;
}

This worked for the solution right up to the point that I decided to add some unit tests to validate my changes.

Symptoms

Locally my unit test worked fine, but when running on a hosted agent the following was the result. Meaning that the unit test did not translate the path to the file as I expected.

Looking into the failure deciding that it could only come from not being able to find a file path.

Digging through the environmental variables of the hosted agent I noticed the culprit. Because the hosted agents also use the environment variable HOME, the path changed and my tests failed.

Solution

Not wanting to add another dependency on deployment, like introducing a new variable that I only set during deployment to notify the code that you are running in a production setting. I started to look around the environment variables on a deployed Azure function. Using the Console option in the Azure portal, requesting the command: printenv, noticing the variable WEBROOT_PATH.

• 

• 

Changing the HOME to WEBROOT_PATH solved the problem of my unit tests not working but introduced a new problem running in the Azure portal.

Error getting categories json file: ActivityLogs/ActivityLogCategories.json. Could not find a part of the path ‘D:\Program Files (x86)\SiteExtensions\Functions\2.0.12950\32bit\ActivityLogs\ActivityLogCategories.json’.

Telling me the variable WEBROOT_PATH was empty at function runtime and, that a relative path could not work because Azure functions are being executed from a program files directory and not the wwwroot. It appears that due to sandboxing some variables are not accessible during runtime, even if you change the scope of the System.Environment.GetEnvironmentVariable(name, EnvironmentVariableTarget.Process); to use the EnvironmentVariableTarget.Machine. So what variables can I use then?

• 

• 

Now while I am changing this piece of code I didn’t want to support something that was only there for testing purposes and asking around a colleague of mine mentioned that there is an interface offered by the AzureFunctions\WebJobs that could provide me with the needed information.

Giving me exactly what I need.

Takeaways

• When using azure functions, environment variables are being used to configure your function. Running in a sandbox some variables are not accessible.
• Use the Kudu interface to identify environments variables instead of running console printenv.
• Use specific descriptive names for your own environment variables instead of generic ones like HOME. This reduces the chance of conflicts with systems that are not maintained by you.
• Using relative paths don’t work, Azure functions are executed from a different location.