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

[Ryan_S]

Hey Ajay,

Glad you're interested in CI with LabVIEW!

The error you're getting is interesting, although I'm wondering if it might be a red herring caused by other errors from the parameters you're providing. A couple key items to point out:

• You are correct, the batch file can accept up to five parameters that allow you to fine tune your build. I mention these briefly in the "Configuration Notes & Common Questions" section of the Getting Started guide. However, these are not required to execute the build; they are meant purely for advanced tuning. If you change your Jenkins command to only be the call to build.bat, does that work for you?
• For more information about the parameters, they're commented out pretty thoroughly inside the batch file. Should you have questions on their functionality though, let me know.
• Yes, the indexing of the command line arguments in LabVIEW starting at 1 is intentional. As is discussed in this document, the first parameter LabVIEW gives you will always be the name of the application, which we have no use for in this context.
• As for why I think your error is a red herring, I think we're going to see some interesting behavior based on the path you're passing in as the second parameter. Note that the second parameter (as is commented in the batch file) is a path to append to the workspace path that jenkins is working in; so something like "\FXP LLB" if you wanted to drop down into a folder below where the autobuild.csv file is located. Since you're giving it an absolute path, things are gonna break...

Moral of the story, give the getting started guide another glance, try running your Jenkins build only calling the batch file (no parameters), and open the batch file for more information on the parameters themselves. And, as always, post back if you have more questions

Thanks!

--Ryan_S

[Ajay_MV]

Ryan_S,

Thanks for the detailed inputs.  I followed your moral of the story and I am able to build my sample project now.  I have few questions though

• I have my projects in SVN with "Needs-lock" property which helps our developers to avoid messing with other's work.  Essentially, we need to lock any VI in SVN before starting to edit it.  And we have it for all of our projects.  It seems Jenkin doesn't get the lock for building and savign the project file.  Unless you have the lock, you wouldn't be able to save the changes.   This caused me an error-8 in the "Set Build Exclusions.vi" which is trying to save the file.  Is there anyway we can introduce this svn-locking mechanism in Jenkin?
• After the build is done, I would like to commit the project changes with an SVN log from Jenkin.  Is it possible to do it in Jenkin?  What's the purpose of post-commit SVN hook files in you github?
• I am still curious on how Jenkins sends the arguments for the batch file and what are all the parameters?
• When I ran Jenkins todya, I didn't see LabVIEW opening up but the build happened in backend.  I assume that Jenkin service runs the LabVIEW in systems account and build the project. 

Thanks,

Ajay.

[Oli_Wachno]

Hi Ajay,

Ajayvignesh_MV schrieb:

• After the build is done, I would like to commit the project changes with an SVN log from Jenkin.  Is it possible to do it in Jenkin?  What's the purpose of post-commit SVN hook files in you github?

What is the purpose of commiting back into SVN? Your build job is not really changing your project. Or are you referring to the infomation being altered during build by LabVIEW?

[Ajay_MV]

Hi Oli,

I have auto increament of my build versions.  Based on the build version number, I'm also changing the folder to be build destination to be updated using [Product Version] tag.  Thus, all these changes in my project file has to be committed back to SVN.  Only then, my following build will have the right version numbers.  Unless I commit back, all my build will have same version numbers.

Thanks,

Ajay.

[Oli_Wachno]

Hi Ajay,

thanks for the clarification. I'm using a slightly different approach: automatic builds are performed on branches, so I don't really care about the build version of the project there. After merging into the trunk I would build my trink manually to create the release version with the correct revision in the lvproj file.

I'm not yet into Continous Delivery.

Sorry, at the moment no further hints than checking the internet or the Jenkins book.

Cheers

Oli

[Ajay_MV]

Hmmm.. In my case, I run the agile-sprint for couple of weeks and each day some bugs get fixed... To test it in subsequent day, I need to build the application everyday.  Based on the testing and bug fixes again in following day, the the building process cycles, and this happens through out the sprint.  Each day's build is differentiated using the build version number... Yesterday would be v1.1.6 and today's would be v1.1.7.   My team always works with the main trunk version and we haven't started branching process in svn.  However, for each day's build like this, as a Continuous Delivery, it would be likely that LabVIEW project file get changed on every build.

🙂

Ajay

[chinghwayu]

Ajayvignesh_MV wrote:

Each day's build is differentiated using the build version number... Yesterday would be v1.1.6 and today's would be v1.1.7.

I hope you mean 1.1.x.6 and 1.1.x.7 where the fourth number is the build number. The third number should be reserved for fixes.

Although you could submit it back to version control, it's not necessary. Instead, use the build number assigned by Jenkins. This build number is an environment variable that you can either pass into or obtain from within your build scipt. Use this number and overwrite whatever build number is in the build spec. You can do this through the application builder API functions.

[Ajay_MV]

Ching-Hwa Yu,

That looks to be nice idea... I could use that for auto-incrementing my build.  I need to work on the VI's provided by Ryan_S in order to achieve it.  Also, I can modify the VIs to avoid saving the project & VIs which can help solving my other problem "svn:needs-lock".  One question though, how can I pass or get build number from Jenkins using environment variables.

[chinghwayu]

Ajayvignesh_MV wrote:

One question though, how can I pass or get build number from Jenkins using environment variables.

I believe the EnvInject Plugin is now part of with the standard installation of Jenkins. As the name implies, this allows you to prepare a clean environment and inject specific variables into the build. You can view your system's envrionement variables at https://URL/env-vars.html/. BUILD_NUMBER is the variable you'll need to use.

[Ryan_S]

Hey Ajay,

Glad to hear that it works! As for your questions, it looks like you've already gotten some good feedback from the community but I figured I'd add my 2 cents:

• For the SVN lock and re-commit to SVN after the build, it sounds like both of these are because you want to increment the build version of your exe and have that saved back to the project for future builds. I agree with Ching and recommend using the Jenkins Job build number for incrementing your exe build number. I use this primarily with my VI package builds, and the script should already be passing in the Jenkins Build number. Look at the case for a VI package build, and you should see the job version passed in; you could then modify the build VI to use it as well. However, if you still wanted to take actions (such as lock, save, unlock, etc) remember that the build script allows you to run VIs (with the VI call in your autobuild.csv) so you could have a VI call before your build call that locks the files, then a VI call afterward to re-commit them. Inside these VIs you would use command line calls to perform the SVN operations.
• As for how parameters are being passed, I recommend opening and reading through build.bat
• As for LabVIEW urnning in the background, this is intentional based on the process calls in build.bat. It's meant primarily so that you can enable multi-instancing of LabVIEW and then run multiple builds at the same time.

--Ryan_S