Using environment variables in build vNext

05 Feb, 2016
Xebia Background Header Wave

The new build system which was introduced in  Visual Studio Team Services (VSTS) and TFS 2015 has been gaining more popularity lately, and (in my opinion) rightly so. It simply works far better than the old XAML builds. I’ve been converting quite a few XAML based builds to the new build system. While doing this, I (inevitably of course) came across quite a few custom build workflows and tasks. Some of these were easily converted to build tasks that are available out-of-the-box, while others required some custom tasks. When creating a custom build or a custom build task, you’ll at some point need some build-specific information. This is where environment variables become necessary. Since I wasn’t too familiar with the concept (I’d heard of them, but never really used them) I decided to dig a little deeper.

What is an environment variable?

Environment variables are a concept within the operating system. They are a set of key-value pairs which are specific to the environment of your current process. The use of environment variables is well known on most operating systems, such as Windows, Linux & Mac OS X. This makes them very useful in cross-platform scenarios, such as a build agent.

Some examples of common environment variables are “PATH” (a list of directories to search for a command you’re executing), “TEMP” (the path to store temporary files) and “WINDIR” (the path to the Windows installation directory).

Environment variables in the build process

In the context of a build job, the current process will be the execution of your build definition. So, any environment variables created in this context are available to all the tasks in your build definition! This means that you can use environment variables inside your build tasks to control the execution of the build task. Also, you’ll be able to pass information from one task to other tasks downstream in the build process.

There will be multiple sources for setting the environment variables:

  • The operating system of your build server: will set server level variables such as “TEMP” and “PATH”,
  • The build agent: will set some variables specific to running a build, such as the agent working folder and things like the build definition that’s being executed and the build number,
  • The build definition: any variables that you set on the “Variables” tab in your build definition (either in the definition itself or when queueing a build) will be available as environment variables in the build job.

For more information regarding environment variables in your build definition you can refer to:

Showing all environment variables

The MSDN page above gives a list of pre-defined variables that are availabe inside your build job. While it provides quite a bit of insight, this wasn’t enough for me. I wanted to know all environment variables that are available, as well as their actual values during the execution of a build. As it turns out, printing all environment variables and their values is actually not that hard. In PowerShell this can be achieved with:

Get-ChildItem Env:

And in Node.js there is an object that contains all environment variables:


You could put this inside the code of any custom build task that you’re developing. However, I decided to wrap this in a small custom build task that will print all environment variables and their corresponding values. This will allow for easy debugging by just including the task anywhere in your build process. You could even include it multiple times to see if and how any environment variables were changed between tasks.

The output of the task looks something like this:


As you can see, there are many environment variables defined. In my case, there were 114…

The code for this task can be found on GitHub. Feel free to use it!

Hopefully this will help you to understand what’s going on in your builds.

Happy building!

[This post is published in Dutch on the Delta-N blog]

Kees Verhaar
Welcome to my blog! I am an ALM consultant for Xpirit Netherlands B.V. Sounds fancy, doesn’t it? Basically it means I help people to do their work as a software engineer better, faster and easier. In the past couple of years of working in the field, I have encountered many things of which I thought: “I should share this!”. This blog is my way of doing that. You’ll find real life stories, tips & tricks, examples and probably even some code here. Hope you enjoy! If you have any suggestions, please feel free to drop me a line.

Get in touch with us to learn more about the subject and related solutions

Explore related posts