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.
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:
The path to the LabVIEW project file
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:
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.