Continuous Integration

[GregFreeman]

Has anyone here set up CI with Bamboo (or Jenkins?). I am working on this now (with Git) but starting with a blank slate with something you hardly know anything about is tough, especially with LabVIEW that doesn't have really any plugins available for it on this front. I would like to first start with just automating a build, then I can start adding in the more complex stuff like kicking back merges etc if the build fails. But, those things are a task I will tackle later.

[PiDi]

We've set up Jenkins once and used it for a brief moment, but it was just experiment to see how it works and we've left this after several weeks. The real show-stoppers were some nasty bugs in compiler in the project that was our guinea pig. Those errors were unrelated to the CI server, but the result was that none of the compilations could be finished. The application builder is very moody - it can break without apparent reason in the first run, just to succeed in second. That is for sure one of the things to considerate when setting up CI.

 

Anyway, I still see many advantages of CI, so I'll follow this thread with interest and maybe come back to the idea.

[GregFreeman]

We've set up Jenkins once and used it for a brief moment, but it was just experiment to see how it works and we've left this after several weeks. The real show-stoppers were some nasty bugs in compiler in the project that was our guinea pig. Those errors were unrelated to the CI server, but the result was that none of the compilations could be finished. The application builder is very moody - it can break without apparent reason in the first run, just to succeed in second. That is for sure one of the things to considerate when setting up CI.

 

Anyway, I still see many advantages of CI, so I'll follow this thread with interest and maybe come back to the idea.

 

Yes, the build can be finicky for sure. I'll see how this works out. Anyways, I am making some headway and when I have something that's at least somewhat substantial I'll post back with my findings.

[ak_nz]

Yes, the build can be finicky for sure. I'll see how this works out. Anyways, I am making some headway and when I have something that's at least somewhat substantial I'll post back with my findings.

 

We built a basic utility we inventively called "GBuild" that is run via command-line when starting LabVIEW. GBuild parses LabVIEW command line arguments (ignoring itself) to determine what project to open, whether to mass compile or clear the compiled object cache, what number to version a build (e.g.with reference to source control version), what unit tests to run (by unit test framework provider, we occasionally use more than one), what VI Analyzer configuration file to use (if required) and then what build specification to execute. We use the command output stream to feed information back to the CI runner (progress, unit test results etc.), which in our case happens to be TeamCity.

 

The actual TeamCity build agent in our case is a virtual machine with the development environment elsewhere on the network. As part of the pre-build process TeamCity automatically checks the source out of source control prior to starting GBuild.

 

This works quite well, even in some scenarios where we "chain" builds (one build is dependent on the previous).

 

The only issue we have had is where we use .NET assemblies as part of a project that is being built - if the .NET assembly version has changed then we have had to add a programmatic "Save All" to avoid LabVIEW hanging at exit with a prompt to save changes (since there is no actual user).

[dannyt]

I do not know if you have seen https://decibel.ni.com/content/thread/8817  on the community web site, it is quite an interesting read plus http://blog.jki.net/news/niweek-2012-fire-and-forget-bulletproof-builds-using-continuous-integration-with-labview-video-slides-now-available/ JKI have a download with some example code for kicking off a build.

 

 

Our main software dev teams C & C++ work on Jenkins for all our builds, but I have not done one for LabVIEW yet. 

 

One problem I have with all this is LabVIEW software licenses. Jenkins here works on a Linux box, I would need to allocate a LabVIEW build PC  (windows)  and put a copy of LabVIEW on that PC for no other reason the the build and I have no spare licenses. I could see how it would work well with the floating license situation, but I am on fixed seats here.

[GregFreeman]

Thanks guy, good responses. This is the feedback I have been looking for. AK_NZ this is pretty much the route I have been beginning to take so that at least confirms I am on the right path. Danny, I don't have the same licensing issue luckily. But, I really appreciate those links. I hadn't come across them and they seem pretty valuable.

[ak_nz]

I do not know if you have seen https://decibel.ni.com/content/thread/8817  on the community web site, it is quite an interesting read plus http://blog.jki.net/news/niweek-2012-fire-and-forget-bulletproof-builds-using-continuous-integration-with-labview-video-slides-now-available/ JKI have a download with some example code for kicking off a build.

 

 

Our main software dev teams C & C++ work on Jenkins for all our builds, but I have not done one for LabVIEW yet. 

 

One problem I have with all this is LabVIEW software licenses. Jenkins here works on a Linux box, I would need to allocate a LabVIEW build PC  (windows)  and put a copy of LabVIEW on that PC for no other reason the the build and I have no spare licenses. I could see how it would work well with the floating license situation, but I am on fixed seats here.

 

Before we had a dedicated build agent PC (well virtual machine, but you get the gist) I actually used my development machine as a build server and scheduled the hours the the agent was available for (typically break times, outside work hours, times I knew it didn't need LabVIEW etc.). Not quite as useful as a dedicated machine but it was able to take advantage of the same license. I could enable or disable the agent when I needed control of LabVIEW back to get some actual work done, and then relinquish it back to the build agent when I was done. Build agents are independent of the build server with TeamCity so if my development machine was unavailable the build server would try and locate another available agent.

 

Thanks guy, good responses. This is the feedback I have been looking for. AK_NZ this is pretty much the route I have been beginning to take so that at least confirms I am on the right path. Danny, I don't have the same licensing issue luckily. But, I really appreciate those links. I hadn't come across them and they seem pretty valuable.

 

The biggest issue we faced was the automation of the LabVIEW IDE. We went through several hoops to make sure that we could shut-down the IDE normally when a "build" was finished. If only LabVIEW, ironically, had a command-line version 

[GregFreeman]

Before we had a dedicated build agent PC (well virtual machine, but you get the gist) I actually used my development machine as a build server and scheduled the hours the the agent was available for (typically break times, outside work hours, times I knew it didn't need LabVIEW etc.). Not quite as useful as a dedicated machine but it was able to take advantage of the same license. I could enable or disable the agent when I needed control of LabVIEW back to get some actual work done, and then relinquish it back to the build agent when I was done. Build agents are independent of the build server with TeamCity so if my development machine was unavailable the build server would try and locate another available agent.

 

 

The biggest issue we faced was the automation of the LabVIEW IDE. We went through several hoops to make sure that we could shut-down the IDE normally when a "build" was finished. If only LabVIEW, ironically, had a command-line version 

What I am doing is launching LabVIEW from the command line, via a batch script that is called from bamboo. I have an input variable that is the path of the VI which does the build using the build API that ships with LabVIEW. Bamboo relies on the response from the application that was launched to determine a passed/failed build. I am now taking the approach my batch file waits for the call to LabVIEW to return, my build VI dumps a log file which holds success/failure inside, and my batch script looks at the file to determine a pass fail. Then, the batch script can return exit(0) or exit(1) itself, which bamboo captures. To get out of LabVIEW, I am fine with just putting an exit LabVIEW function in my VI that does the build, since this VM will be dedicated to builds. Whew.

 

Edit: I did try launching LabVIEW directly from Bamboo. While this did launch LabVIEW, calling exit (0) or exit(1) from LabVIEW using the CLFN crashed LabVIEW. So, there was no way to tell Bamboo that the build failed or succeeded, as it would always fail. This is why I wrapped it in a batch script and let the script return 0 or 1.

 

Edit #2: I am open to more robust ideas here

Edited September 29, 2014 by GregFreeman

[ak_nz]

What I am doing is launching LabVIEW from the command line, via a batch script that is called from bamboo. I have an input variable that is the path of the VI which does the build using the build API that ships with LabVIEW. Bamboo relies on the response from the application that was launched to determine a passed/failed build. I am now taking the approach my batch file waits for the call to LabVIEW to return, my build VI dumps a log file which holds success/failure inside, and my batch script looks at the file to determine a pass fail. Then, the batch script can return exit(0) or exit(1) itself, which bamboo captures. To get out of LabVIEW, I am fine with just putting an exit LabVIEW function in my VI that does the build, since this VM will be dedicated to builds. Whew.

 

Edit: I did try launching LabVIEW directly from Bamboo. While this did launch LabVIEW, calling exit (0) or exit(1) from LabVIEW using the CLFN crashed LabVIEW. So, there was no way to tell Bamboo that the build failed or succeeded, and it would always fail.

 

We do the same thing - since the command output stream is already hooked back to TeamCity we don't need any content in the result log file - it's presence (or not) indicates whether the LabVIEW process finished successfully or not.

[GregFreeman]

We do the same thing - since the command output stream is already hooked back to TeamCity we don't need any content in the result log file - it's presence (or not) indicates whether the LabVIEW process finished successfully or not.

I thought about this route but if it fails I wanted to be able to add errors to the file. I suppose I could do if finished and file doesn't exist, success, if finished and file exists, failed.

[ak_nz]

I thought about this route but if it fails I wanted to be able to add errors to the file. I suppose I could do if finished and file doesn't exist, success, if finished and file exists, failed.

 

If you don't have the option of extracting information form the output stream with your Bamboo thingy-a-bob then this would be your best option.

[GregFreeman]

extracting information form the output stream

I probably do. I'll look into this.

[JamesMc86]

Most solutions I have found have done that, used a batch file and then used files on disk to communicate between that and LabVIEW.

 

I started work on a build server written in LabVIEW that communicates with a Jenkins plugin over TCP. I'm hoping it can be a more robust solution but I need to get back around to reviving it later this year. This does mean getting your hands dirty with some Java as well.

 

I'm hoping to pick this up again in the next few months as it would be a useful tool to have and will report back if I get somewhere.

[GregFreeman]

We built a basic utility we inventively called "GBuild" that is run via command-line when starting LabVIEW. GBuild parses LabVIEW command line arguments (ignoring itself) to determine what project to open, whether to mass compile or clear the compiled object cache, what number to version a build (e.g.with reference to source control version), what unit tests to run (by unit test framework provider, we occasionally use more than one), what VI Analyzer configuration file to use (if required) and then what build specification to execute. We use the command output stream to feed information back to the CI runner (progress, unit test results etc.), which in our case happens to be TeamCity.

 

The actual TeamCity build agent in our case is a virtual machine with the development environment elsewhere on the network. As part of the pre-build process TeamCity automatically checks the source out of source control prior to starting GBuild.

 

This works quite well, even in some scenarios where we "chain" builds (one build is dependent on the previous).

 

The only issue we have had is where we use .NET assemblies as part of a project that is being built - if the .NET assembly version has changed then we have had to add a programmatic "Save All" to avoid LabVIEW hanging at exit with a prompt to save changes (since there is no actual user).

 

How did you go about writing to the output stream? I used the VI found here and it writes to the console, but it isn't captured by Bamboo (although my echod commands in my batch file are, so I know bamboo does get this stuff). I may just write to a file and have my batch script read from the file and echo its contents after the fact as James mentions but it would be nice if I could get it to update in real time and let the tool stick everything in its native log file. In the meantime, I will confirm Bamboo will get StdOut so I'm not chasing something that's impossible

[ak_nz]

How did you go about writing to the output stream? I used the VI found here and it writes to the console, but it isn't captured by Bamboo (although my echod commands in my batch file are, so I know bamboo does get this stuff). I may just write to a file and have my batch script read from the file and echo its contents after the fact as James mentions but it would be nice if I could get it to update in real time and let the tool stick everything in its native log file. In the meantime, I will confirm Bamboo will get StdOut so I'm not chasing something that's impossible

 

We pretty much use the VI from that thread. I've attached our copy (LV2012 onwards). I can't say much about Bamboo, but when we use TeamCity it is looking for tokens in the stream that indicate specific messages. That's how we transmit status messages (progress) as well as unit test results etc.

 

I do recall having issues executing a batch file and then receiving messages though - currently we execute scripts manually in TeamCity (ie. it opens a command window and then feeds each line as StdIn). Perhaps this is related to your issue?

Write to Console Standard Out.vi

[ShaunR]

How did you go about writing to the output stream?

 

Ssssshhh, Don't tell Rolf. But there is a superb library that no-one is supposed to use.

[GregFreeman]

We pretty much use the VI from that thread. I've attached our copy (LV2012 onwards). I can't say much about Bamboo, but when we use TeamCity it is looking for tokens in the stream that indicate specific messages. That's how we transmit status messages (progress) as well as unit test results etc.

 

I do recall having issues executing a batch file and then receiving messages though - currently we execute scripts manually in TeamCity (ie. it opens a command window and then feeds each line as StdIn). Perhaps this is related to your issue?

Thanks, that direction should get me started.

 

 

Ssssshhh, Don't tell Rolf. But there is a superb library that no-one is supposed to use.

[GregFreeman]

We pretty much use the VI from that thread. I've attached our copy (LV2012 onwards). I can't say much about Bamboo, but when we use TeamCity it is looking for tokens in the stream that indicate specific messages. That's how we transmit status messages (progress) as well as unit test results etc.

 

I do recall having issues executing a batch file and then receiving messages though - currently we execute scripts manually in TeamCity (ie. it opens a command window and then feeds each line as StdIn). Perhaps this is related to your issue?

To follow up, when I launched with "start /b /wait" I was then able to redirect my stdout from LabVIEW to a file. Before it would print to the console but it was like that stdout stream wasn't seen as the one that the start command was referencing because the redirect just left me with an empty file.

start /b /w LabVIEW.exe <VI Path> > %USERPROFILE%\output.txt

Haven't checked if Bamboo captures this yet, that is my next step. But, the fact that i can now redirect an output from the start command to a file gives me hope. If nothing else, I should be able to execute a loop on the stdout from LabVIEW and echo the response which I know Bamboo can get.

FOR /F ["options"] %%parameter IN ('command to process') DO command

Just in case it helps anyone else...

 

Edit: Just confirmed, the /b option allowed bamboo to capture what I wrote to stdout

Edited October 4, 2014 by GregFreeman

[RobP]

I understand how to call a LabVIEW VI from Bamboo and pass in parameters but I have no idea how to return any pass/fail results back to Bamboo or if I even should.  Any one have any suggestions?