The Continuous Delivery Machine Part 1: Build Engine

Introduction

In preparation for my presentation at NIWeek 2016 on Continuous Delivery (CD), I’ve compiled some of the key concepts used to implement a CD machine to deploy LabVIEW-based applications. I’ve decided to share some of the details with the community in order to help others in their journey of implementing Continuous Integration (CI) or Continuous Delivery (CD). In a series of blog posts, I hope to cover a variety of Agile and CD concepts that have catapulted my team at Texas Instruments into a lean mean development machine.

Build Engine

The build engine is a core component of the machine. There is the starting point of any CD toolchain and you simply can’t live without it. But where do you get started?

LabVIEW Build API

To programmatically build a LabVIEW specification, utilize the build APIs that are under the Application Control palette.

The most important function is Build.vi. The inputs are:

1. The path to the LabVIEW project file
2. Name of build specification

Calling this will build any specification within a project. If the specification doesn’t exist or if there’s a build error, the build output will be included into the source within the error output cluster.

Both Get Build Specification Version.vi and Set Build Specification Version.vi are also important as this allows you to inject a different build number than the one stored within the project file. More on this will be discussed in a future blog post dedicated to Automation.

LabVIEW Command Line Arguments

When LabVIEW is launched from the command line, arguments can be passed to the application to be as build parameters. For example:

"C:\Program Files (x86)\National Instruments\LabVIEW 2014\LabVIEW.exe" "LV_argument.vi" -- arg1 arg2

This will pass arg1 and arg2 as the two strings. It’s important to index from position 1 to obtain the arguments as index 0 will return “LabVIEW”.

From this, we can pass in the build arguments into the build API. This will allow us to send in the project path, build specification, and build number as parameters.

"C:\Program Files (x86)\National Instruments\LabVIEW 2014\LabVIEW.exe" "LV_build.vi" -- MyProject.lvproj MyApp 43

Ok, now that we’re able to programmatically build using parameters, how do we get outputs back to the command line? What if we wanted to know the paths of the generated files or the source of a build error?

LabVIEW Command Line Interface

The only published method to obtain results is from a JKI blog post (link) back in 2012 following their presentation at NIWeek. This method uses two temporary files, one to determine if the LabVIEW build process and the second to record the error if one occurred. If the error file was not empty, the contents would be “typed” to be pushed back to the command line.

This was done since there’s no direct method to write back to the command line (console) from LabVIEW. While this works, it’s a bit clunky and not easily scalable in case you wanted to build multiple specifications simultaneously. I should mention that there’s a method to write to the console posted on LAVA (link) that involves both .NET and DLL calls, which isn’t a straightforward implementation.

Fast forward to the 2016 CLA-E Summit where James McNally from Wiresmith Technology introduced a command line application (link) that serves as a proxy between the console and LabIVEW. This is an excellent tool that allows you to publish anything as part of the build output whether its status, generated files, or error source.

You can either install the library and C# application or place it alongside your build project. It’s fairly simple to use and instructions are provided at gitbhub.

Here’s an example after putting it all together:

"C:\Program Files (x86)\Wiresmith Technology\LabVIEW CLI\labview-cli" "LV_build.vi" -- MyProject.lvproj MyApp 43