Configure a VSTS Linux agent with docker in minutes

It is really simple to create a build agent for VSTS that runs in Linux and is capable of building and packaging your DotNetCore project, I’ve explained everything in a previous post, but I want to remind you that, with docker, the whole process is really simple.

Anyone knows that setting up a build machine often takes time. VSTS makes it super simple to install the Agent , just download a zip, call a script to configure the agent and the game is done. But this is only one side of the story. Once the agent is up, if you fire a build, it will fail if you did not install all the tools to compile your project (.NET Framework) and often you need to install the whole Visual Studio environment because you have specific dependencies. I have also code that needs MongoDB and Sql Server to run tests against those two databases, this will usually require more manual work to setup everything.

In this situation Docker is your lifesaver, because it allowed me to setup a build agent in linux in less than one minute.

Here are the steps: first of all unit tests use an Environment Variable to grab the connection string to Mongodb, MsSql and every external service they need. This is a key part, because each build agent can setup those environment variable to point to the right server. You can think that 99% of the time the connection are something like mongodb://localhost:27017/, because the build agent usually have mongodb installed locally to speedup the tests, but you cannot be sure so it is better to leave to each agent the ability to change those variables.

With this prerequisite, I installed a simple Ubuntu machine and then install Docker . Once Docker is up and running I just fire up three Docker environment, first one is the mongo database

sudo docker run -d -p 27017:27017 --restart unless-stopped --name mongommapv1 mongo

Than, thanks to Microsoft, I can run Sql Server in linux in a container, here is the second Docker container to run MSSQL

sudo docker run -e 'ACCEPT_EULA=Y' -e 'SA_PASSWORD=my_password' -p 1433:1433 --name msssql --restart=unless-stopped -d microsoft/mssql-server-linux

This will start a container with Microsoft Sql Server, listening on standard port 1433 and with sa user and password my_password. Finally I start the docker agent for VSTS

sudo docker run \
  -e VSTS_ACCOUNT=prxm \
  -e VSTS_TOKEN=xxx\
  -e TEST_MONGODB=mongodb://172.17.0.1 \
  -e TEST_MSSQL='Server=172.17.0.1;user id=sa;password=my_password' \
  -e VSTS_AGENT='schismatrix' \
  -e VSTS_POOL=linux \
  --restart unless-stopped \
  --name vsts-agent-prxm \
  -it microsoft/vsts-agent

Thanks to the –e option I can specify any environment variable I want, this allows me to specify TEST_MSSQL and TEST_MONGODB variables for the third docker container, the VSTS Agent. The ip of mongodb and MSSql are on a special interface called docker0, that is a virtual network interfaces shared by docker containers.

image

Figure 1: configuration of docker0 interface on the host machine

Since I’ve configured the container to bridge mongo and SQL port on the same port of the host, I can access MongoDB and MSSQL directly using the docker0 interface ip address of the host. You can use docker inspect to know the exact ip of the docker container on this subnet but you can just use the ip of the host.

image

Figure 2: Connecting to mongodb instance

With just three lines of code my agent is up and running and is capable of executing build that require external databases engine to verify the code.

This is the perfect technique to spinup a new build server in minutes (except the time needed for my network to download Docker images 🙂 ) with few lines of code and on a machine that has no UI (clearly you want to do a minimum linux installation to have only the thing you need).

Gian Maria.

Pause build and clear long build queue

In VSTS / TFS Build system, you can change the status of the build, between three states: Enabled, Paused and Disabled. The Paused state is really special, because all the build trigger are still active and builds are queued, but all these queued build does not starts.

image

Figure 1: Paused build

Paused state should be used with great care, because if you forget a build in this state, you can end up with lots of queued build, as you can see in Figure 2:

image

Figure 2: Really high number of build queued, because the build definition is paused.

What happened in Figure 2 is that some user probably set the build to paused, believing that no build will be queued, after some week he want to re-enabled, but we have 172 build in queue.

Now if you are in a situation like this, you probably need to remove all queued builds before re-enable the build definition. If you set the build to active you have the risk to completely saturate your build queue. To solve this problem, just go to the queued tab of the build page.

image

Figure 3: Tab queued for the build page

From this page you can filter and show only queued build for the definition that was paused, you can then select all queued builds, and then delete all scheduling at once. Thanks to the filtering abilities present in the queued tab, you can quickly identify queued build and do massive operation on them.

Now that we deleted all the 172 queued build, we re-enabled the build without the risk of saturating build queue.

Gian Maria.

Check Angular AoT with a TFS Build

Developing with Angular is a real fun, but usually during development you serve the application without any optimization, mainly because you want to speedup the compilation and serving of your Angular application.

When it is time to release the software, usually you build with –prod switch and usually you also use the –aot switch (it seems to me that it is on by default on –prod in latest version of the ng compiler). The aot switch enable the Ahead of Time compiling, that is used to speedup your deployed application and also it find some more error than a normal compilation.

I do not want to made examples when a simple ng build compile just fine but the production build with aot fails, the important concept is, when you fire your production build to generate install packages, it is really annoying to see your angular build fails because of some errors. Since building with aot is really expensive I’ve decided not to trigger this build for each commit, but only for special situations. First of all, here is the whole build.

image

Figure 1: Build to check aot compilation

As you can see, with TFS Build it is really a breeze to create a build that simply trigger the ng compiler to verify that it correctly compiles with aot switch on. Thanks to the trigger panel of my build, I’ve decided to build automatically only master and release branches.

image

Figure 2: Trigger configuration for my AOT build

This is another great advantage of Git over a traditional source control system, I can configure a single build for every branch on my repository. In this specific situation I require that the build will be triggered for release and master branches.

This is usually a good approach, but I want to move a little bit further so I configure that build as optional for pull request for develop branch. With this technique, whenever a pull request is done on the develop branch, that build is triggered, and people can fix errors before they slips to the main develop branch.

Thanks to VSTS build system, it is just a matter of minutes to setup specific build that checks specific part of your code, like angular production compilation and optimization.

Gian Maria.

Choose agent at build queue time

This is a simple feature that is not known very well and deserve a blog post. Sometimes you want to queue a build to a specific agent in a queue and this can be simply done using agent.name as a demand.

Demands are simple key/value pairs that allows the build engine to choose compatible agents and each agent automatically have a couple of capability to store computer name and agent name (they can be different)

image

Figure 1: Capability of agentes, computer name and agent name are automatically present

This allows you to use one of them if you want to run a build on a specific machine, just queue the build and use the demands tab to add agent.name or agent.computername demands.

image

Figure 2: Choosing specific agent at queue time with agent.name capability

If you specify a name that is not valid you will get a warning, if the queue contains that specific agent the build will be queued and will be executed only by that agent.

This technique is useful especially if you add a new agent and want to trigger some specific build on it to verify if it has all the prerequisite ok.

Gian Maria.

VSTS agent on Ubuntu 16.04 error in configure.sh

I’ve downloaded the build/release agent from VSTS page to install in my Ubuntu 16.04 system, but when I tried to run the configuration shell script I got the following error

Failed to initialize CoreCLR, HRESULT: 0x80131500

This happens because I installed the version for Ubuntu 14.04 and not the one specifically compiled for Ubuntu 16.04. In my situation the error happened because the download page of my VSTS account does not list the version for Ubuntu 16.04, but only for Ubuntu 14.04 and this incorrectly lead me to the false belief that it works for both versions. The page from where you download the agent is https://myaccount.visualstudio.com/_admin/_AgentQueue and should also list the version for 16.04.

image

Figure 1: Agent download page in your VSTS account.

To avoid error the best way to download the agent is checking the official GitHub account page.

The best place to download and to look for VSTS agent information is the official GitHub page.

As you can verify from Figure 2, we have a two distinct compiled version for Ubuntu.

image

Figure 2: Distinct builds for vsts agents (Ubuntu 14 and 16)

To download the correct version, you can easily go to the release page (https://github.com/Microsoft/vsts-agent/releases) where you can download all official versions for all supported operating system / version.

Gian Maria.