Programmatically Changing Build Version

[StevenGarcia]

We are wanting to automate our build process and we have a particular problem. We have been looking into the Jenkins tool and quite possibly, LabVIEW 2011 may help us out when we upgrade, not sure though.  But before we look outside of LabVIEW for a solution, we want to run this dilemna by some of the LabVIEW users. We are using the Unit Test Framework and let's say we have some unit tests in our project. We wrote a wrapper VI that will do the following:

1) progammatically execute the unit tests using the Run Tests from File.vi.

2) unbundle the test status from the output cluster array and look for a "Passed" result

3) if the result is indeed "Passed" then this means that the overall results for the unit tests are OK and go ahead and call the Build Targets Programmatically.vi with the appropriate path, name of build and target. The name of the build is set in the properties of the build specification in the project.

This works fine. What we want is the ability to either auto-increment the version number (which the checkbox is selected in the build properties) or set a version for the build. Only when you press the Build button in the build specification properties does the version get incremented automatically, not via programmatically.

[TiTou]

I suggest you take a look at this, it could help you.

I've never used the Unit Test Framework so I don't know if you can integrate the build action into it, but surely you can fire a build programmatically.

Hope this helps

[BenDAE]

Interesting application! Are you giving it a build specification or leaving that empty? 

[TiTou]

You can do alot in fact, there's many threads on LAVA about how to edit build specs and run build specs.

Of course you can select the build spec you want to run. But I'm not sure I understand you question...

Hope this helps

[StevenGarcia]

Sorry for the delayed response. We had to create the build specification first in the project except we did not actually perform a build. Then we gave the field the name of the specification because if you leave it empty it performs a 'build all' and we don't want that. Also an update on the version number - it does auto-increment the field as long as the checkbox in the build properties is selected, but we want more control over what part of the field gets incremented. For instance, the current behavior is if the version was 1.0.0.3 before running the unit test, the unit test runs & passes and then the build specification fires off and performs a build, the new version is 1.0.0.4. What if we have major changes to the software and want to execute the unit tests before we build and bump the version to say 1.1.0.0?

[clendon.gibson@canrig.com]

This thread on the LAVA forums explains how to read the Build version number in the build spec.

 https://lavag.org/topic/10643-programmatically-modifying-buildspec/

You can use the Set tag properties to change the build number after you have the build spec reference. Make sure to use an integer. Strings will run without error, but won't actually work when you run the build.

[Bob_Schor]

In versions before LabVIEW 2014, this was truly difficult, as the Version Number for a particular Build Spec is stored deep within the XML that is part of a Project (modify at your own risk).  There are also some inconsistencies in the XML Tags, in particular whether the third dotted number of the Build Spec is called "Fix" or "Patch".

LabVIEW 2014 introduced a Set Build Specification Version that allows you to set the Build Spec within the Project by supplying the name of the Target (usually "My Computer"), the name of the Build Spec, and the path to the Project file.  There is also in LabVIEW 2012 and higher (I don't know if this is present in LabVIEW 2011) a Build option called a Pre-Build Action, whereby you can specify a VI to run before the Build takes place.

In my LabVIEW implementation, my LabVIEW Projects live inside folders that are part of a SubVersion repository.  I wrote a utility that, given the path to the Project File, can return the SubVersion Build number.  Using the Pre-Build Action, I can call this Utility, get the SVN Build Number, and use Set Build Specification Version (or other LabVIEW code to diddle the Project XML file directly).

This, in fact, works, but there's a bug -- the file that results from this Build does not have the Build number specified by the Pre-Build Action.  It turns out that as part of the Build process, the Version is cached first, then the Pre-Build Action is applied (updating the Version, perhaps), then the Build takes place using the cached Version.  The "simple fix" is to Build twice -- the first time to save the SVN Version into the Build Version number, the second time to use this saved Version number in accomplishing the Build.

I've alerted NI to this conundrum.  I didn't get the sense that they are willing or eager to change this behavior.

Bob Schor

[clendon.gibson@canrig.com]

Hi Bob,

Thanks for the tip about Set Build Specification Version. I am on 2009 at the moment, but we are planning to move to 2014 for some of our projects.

I'm not sure why you would directly modify the XML when you can have LabVIEW do it for you. If you get a reference to the Build Specification in the project you can read and write the "tag" values which correspond to the elements in the XML file. I have attached a snippet to demonstrate.

Another solution to the issue of building twice is to execute builds from outside the project. A seperate LabVIEW program can update the version in the Build Spec, and then programmatically launch the build.

Here is a link for that second step.

https://decibel.ni.com/content/docs/DOC-2168

I am working on an autobuilder now and have good results so far with this.

[Taki1999]

---

clendon.gibson@canrig.com wrote:

I am working on an autobuilder now and have good results so far with this.

---

Be careful with your snippet. NI changed the XML tags so that your build specs in later versions of LabVIEW will not reflect the change correctly.

(i.e. App_fileVersion.build changes names between LabVIEW 2011 and LabVIEW 2013.)

 EDIT: I do the same thing Bob does and just build twice.

[Bob_Schor]

---

I'm not sure why you would directly modify the XML when you can have LabVIEW do it for you. If you get a reference to the Build Specification in the project you can read and write the "tag" values which correspond to the elements in the XML file. I have attached a snippet to demonstrate.

I am having LabVIEW do it for me, using a method similar to that shown in the LAVA article.  This does modify the XML that makes up the LabVIEW Project, which was my meaning.  As far as I know, the structure of the Project XML is "supposed to be" hidden from us, and can vary widely between LabVIEW Versions.  I also think (in a discussion with NI AE's) that this is something that NI would prefer we avoid.

Another solution to the issue of building twice is to execute builds from outside the project. A seperate LabVIEW program can update the version in the Build Spec, and then programmatically launch the build.

Thanks.  I'm looking for a way to use LabVIEW and its Project tools to do the things that LabVIEW is "supposed" to do, like build executables.  If they provide a "Pre-Build Action" section and encourage (or maybe merely allow) us to do things before the Build actually takes place, then (to my simple-minded logical reasoning) it should do those things before the Build actually takes place.  Since Builds of my Projects (including a Build All of my Real-Time project, with about 7 Build Specs for the main routine and support routines) takes only 2-3 minutes, I prefer to do two Build All's and have my Project remain as "vanilla LabVIEW code" without requiring an external program to "fake" the Pre-Build Action + Build for me.

Bob Schor