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.
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.
10-09-2015 11:38 AM
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
11-11-2015 09:52 AM
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
11-11-2015 05:08 PM
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
11-12-2015 01:08 AM
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!
11-12-2015 01:14 AM
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
01-25-2016 10:02 AM
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:
01-25-2016 10:11 AM
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
03-04-2016 09:18 AM
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
03-04-2016 09:42 AM
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
05-11-2016 08:27 AM
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.
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.