From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Continuous Integration

cancel
Showing results for 
Search instead for 
Did you mean: 

General Discussion/Questions about LabVIEW/Jenkins with the Batch File Build Process

Hey Oli,

That's great to hear! I'm glad everything is working; let me know if you have any feedback on the batch file system itself or the getting started doc. Again, glad you found this approach with Jenkins useful.

Thanks! --Ryan

0 Kudos
Message 11 of 38
(4,488 Views)

Hi everybody,

I keep putting more and more build jobs for ppls into Jenkins. An issue I have seen is that builds with dependencies seem to be a problem:

Let's say libraries B & C are depending on library A. I have configured the build jobs for B&C to be triggered on sucessfull build of library A. Jenkins starts both builds in parallel, but only one succeeds, the other on will be hund after some time.

Has anybody else seen this behaviour?

Cheers

Oli

0 Kudos
Message 12 of 38
(4,488 Views)

Hmm, well you can definitely have problems if you're using shared resources (i.e. if you tried to run 2 VI package build jobs they would clash and 1 or both would hang since VIPM is a shared resource) but I guess it depends on how you're calling the library. Are you having jobs B & C reference the same built copy of A? Usuaully you would have B & C pull a copy of A into their individual workspaces for their build and I can't see that causing problems since even though it's the same named library they'd be in different instances of LabVIEW.

Thoughts?

--Ryan_S

0 Kudos
Message 13 of 38
(4,488 Views)

Dependencies are ok,  at the moment I even have lib A directly placed in the respective source directory of Libs B & C. (will be an external definition in SVN as soon as I have defined, where the respective libs will be placed within the repo)

But yes, I guess there is some issue about shared ressources. If a build gets hung on the console output you can see, that the build.vi is never called (autobuild.csv not read) since the console output is completely missing.

Just wanted to verify and found out, that this time, two builds would run in parallel (manually started), the third one was started a moment later and got stuck. I suppose there is some issue with the files used for synchronization of Jenkins & the LabVIEW build process.

At the moment I can live with this, it's a known issue and there is a (at least for the moment) feasible workaround.

Thanks for your ongoing support!

0 Kudos
Message 14 of 38
(4,488 Views)

Just another hint for all users

I have stumbled across the issue, that consecutive builds would fail reporting

Error 74: Invalid data structure ....

This turns out to be an issue of of the SCC checkout strategy for the particular job: it disappeared when I set it to Always check out a fresh copy

0 Kudos
Message 15 of 38
(4,488 Views)

Me again

I eventually made it to configure a build using more than one LabVIEW Version.

My current active version is 2013, I added 2014.

Things which made me stumble:

  1. Building only in 2014 failed (no response from LabVIEW on the console output) due to missing OpenG VIs in 2014
    Possible Solution: Try to open (not save!) Build.vi with every version you want to use and check for errors
  2. Consecutive builds can cause license trouble if you're running on a VLA license: LV2013 does not shut down, before 2014 launches and tries to check out a license.
    Possible Solution: Configure LabVIEW to ignore these errors and NOT show a dialog box (which causes LV to "hang" when running in the background). Telling from the task manager, LabVIEW 2013 seems to not shut down before both builds are finished
0 Kudos
Message 16 of 38
(4,488 Views)

Hey Oli,

Thanks for posting these back to the community!

I've never tried to run jenkins on a VLA; kudos for troubleshooting and working around those errors!

--Ryan_S

0 Kudos
Message 17 of 38
(4,488 Views)

Coming up with a new issue today:

Lately, I have started organizing my build jobs on Jenkins using folders to clean up a bit. This went along with Build.vi throwing funny errors of not having found some paths. This error occured always after the execution of the last build item.

Diggin a bit deeper, I found out, that Build.vi creates (temporary) folders in C:\Builds which seems to cause troubles.

So I moved my Build Job back to Jenkins root.... et voilá everything is working again

In case somebody else stumbles across sth like this

0 Kudos
Message 18 of 38
(4,488 Views)

Hey Oli,

Yes, build.vi copies all of the completed built files to c:\builds at the end of the build process. We use this in our process so that we can network share that folder and others can access the latest builds.

If you don't need this functionality, you can diagram disable (or delete) the copy code in build.vi. It won't affect any of the core building features.

--Ryan_S

0 Kudos
Message 19 of 38
(4,488 Views)

Guys... Good day to you all..!  Kudos to Ryan_S for this effort... I gave a sample try with my LabVIEW 2014 and I'm stopped with some issues. 

  1. I am able to run build.bat with arguments to trigger the build from cmd prompt, however when I build with Jenkins I'm getting the PING error (quoted below)... I am sure my environment variables are set properly and so the build.bat executes without issue when I run it independently.
  2. I found that build.bat file needs some 5 arguments which is not explained in the document.  I gave these arguments (highlighted in below quoted text) explicitly in Jenkin configuration.  Is this correct way?  If not, from where these arguments comes to batch file?does the Jenkin will pass these arguments?
  3. I found that indexing of the command line arguments is started at "1" in "Build.vi".  Only after chaning that to "0" and other indices, my direct execution of build.bat worked in cmd prompt.  Is that indexing from "1" is intentional?

Started by user anonymous

Building in workspace C:\Program Files (x86)\Jenkins\workspace\Sample Project Build

Updating https://svn.tessolve.com/svn/LabAutomation/Workspaces/Ajay Workspace/JenkingTest at revision '2016-05-11T16:01:47.614 +0530'

AU        Sample Proj.lvlps

AU        Sample Proj.aliases

AU        Autobuild.csv

U         Sample Proj.lvproj

At revision 1723

[Sample Project Build] $ cmd /c call C:\Windows\TEMP\hudson4211982921074233364.bat

C:\Program Files (x86)\Jenkins\workspace\Sample Project Build>C:\Autobuild\Jenkins-Autobuild\build.bat 2014 "D:\Workspace (Ajay SVN)\JenkingTest" f "" 0

Skipping version check on request

Running specific version build: LabVIEW 2014

  Starting 2014 build...

'PING' is not recognized as an internal or external command,

operable program or batch file.

'PING' is not recognized as an internal or external command,

operable program or batch file.

'PING' is not recognized as an internal or external command,

operable program or batch file.

'PING' is not recognized as an internal or external command,

...

Thanks,

Ajay.

--
Ajay MV


0 Kudos
Message 20 of 38
(4,486 Views)