Automatic Build System for LabVIEW

[Vladiator]

Does anybody have any documentation on how to setup Jenkins to use it for LabVIEW apps? Can it be also integrated with Visual SourceSafe or the code must be archived in other SCM systems?

[Mike_King]

There is a plugin for jenkins to integrate with most scc systems, visual ss included:  https://wiki.jenkins-ci.org/display/JENKINS/Visual+SourceSafe+Plugin

We have not published any documentation for this at this time and never found any with extensive searching when we first started using it.  Its not that tough, once you start looking at the labview API for running tests and builds, you have to invent what kind of reports and results you really want out of it though, as that is what we spent most of our time customizing.

[PatrikC]

We have recently tried a simmilar approach with TeamCity, alltough not with all the wrappers to execute unit test framework and building. The goal was to execute tests on a target machine were the repository was "exported" from a SVN repository and then executet thru batch scripting. Is it possible to let Jenkins/Hudson export a filestructure from a repository to a "build agent" as it is in TeamCity?

[Mike_King]

jenkins is simply an execution system and plugin system, so not directly, but it would be very easy to do with a command line equivalent like xcopy or some repository mirroring command that can copy the data elsewhere.  I'm not sure why you wouldn't just enable network access though and access the repository directly, then you don't need to do the remote copy and have delays in transfering files, just access them on the network and you should be able to achieve what you want.

We run our tet devices on a VLAN but can easily enable network links to our repositories to allow them to have source access as well as test environment access.

[PatrikC]

Well, in this case the "export" could be done on the "latest" version, or a "labeled" version on the test system repository or the actual FW repository in different Team city build configurations. The FW is the real target for the tests in the continuous integration and it was downloaded to target HW. The testsystem provided measurement and stimuli for the target HW. 

So different Team City "builds" actually could handle an export based on different versions of the source code. It was quite nice flexibillity to let the execution system "download" it's version of code to execute to the teststation.

I guess the same thing could be achived by changing system's "view" of the repository and load from network instead.

I like the VLAN way of executing the test though, Nice . Will think about that......

Anyway, i see from this thread that it is possible to use Hudson and that is great news. The question of how to  "extract" the code to execute is a later problem .

[Mike_King]

Ya for sure and good points Patrik. We extensively use branching in Perforce to achieve our VIEWS of interest into our repository and so that branch is essentially our label or version under test while other work can still be branched off elsewhere and merging back into our trunk repository, which has its own suite of tests. We basically enable a project in jenkins for each branch that needs testing and integration and run them all.  I'm not sure how Jenkins and TC compare, I've not used TC yet, so not sure if you are looking to move to jenkins or use it with TC in some way.  I imagine they would both be just as capable?

The binary issues in LabVIEW are always the hard part of integrations with a large development team.  I really wish NI would get a proper auto-merge tool and API for LabVIEW code.  It's a huge roadblock.

[PatrikC]

Just wanted to get back on the progress to you Mike, thanks for your input

In the current project we are now using a jenkins server and a VMWare system were we configure Nodes for Unit tests, System tests (simulated HW) and Build procedure. Works very nice. Our customer has the same environment (but a Hudson server) but here we can use a Node with Measurement Hardware to actually run System Tests on target. So we deliver the Testenveronment with continuous integration together with the Application, eventually the customer recieves the project infrastructure for maintanence.

There are millions of improvments to do but the main direction is set and it will work.

[Mike_King]

Good to hear Patrik, continous integration is a powerful capability for product development.  We rely heavily on ours for all of our development areas, LabVIEW, Java, c#, javascript, html, silverlight.

[pavanb]

I just saw this thread after posting,

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Separating-compiler-and-editor-and-or-targeting-anothe...