automatic builds with GitLab

[ensegre]

Anyone using, are there recommendations or tips to share? Following to my whines for a serious internal SCC, I got my IT to install Gitlab CE on an internal server, and I'm happily tucking with it so far. I see that Gitlab should have a product called Gitlab CI (continuous integration) as well as the option of webhooks to external services, I wonder what else it would take to have the functionality working, with private availability of the build. E.g. which build script, where sits LV, cross-platform builds if relevant, periodicity of the build (every commit? nightly? tagged? only last?) etc.

 

General pointers to how automated builds (specifically LV) are handled by other SCC also appreciated, for my education.

[joerghampel]

I've been using gitlab for some time now (hosted on gitlab.com), and mentioned it just a few days ago here and also on the NI LAF. Although I'm still far from 100% build automation, I can happily share my experiences so far.

 

FYI: Some of my process and structure decisions are due to the fact that I'm a 100% Apple guy, working on Apple computers. As all of my customers are using Windows, I do the LabVIEW programming itself in VMware virtual machines. I try to keep these Windows machines disconnected from the internet to keep things simple and secure. The directories containing the LabVIEW projects are accessible both from Windows and Mac OS. 

 

Now, back to the topic:

• Gitlab itself is great IMHO. I chose it for its web interface, its integrated issue tracker and its API (which I use to connect from my Dokuwiki), and all of that is working very well for me.
• I use the Tower Git Client in Mac OS for pushing/pulling/publishing. In Windows, I use the git binaries, calling them automatically from LabVIEW build scripts.

Concerning the continuous integration:

• I have a Jenkins CI server running on Mac OS
• The Gitlab CI service seems to work best for me for triggering the Jenkins server. I've also tried web hooks and the Jenkins CI service, with varying results. 
• As to the periodicity, I'm still running the build scripts manually for most of my customer projects. For some internal tools (our "products"), I configured gitlab to trigger the Jenkins server whenever I pu(bli)sh a new tag. Jenkins then in turn calls the same build scripts automatically that I run manually - more or less ;-)
• As mentioned above, my working environment doesn't allow Windows to connect to the internet, so I have configured Jenkins as a Master/Slave system, with the master running on Mac OS, and the slaves running inside the Windows virtual machine
  • The master pulls the latest revision from gitlab.com, to a directory that is accessible from the slave in Windows
  • As a post-build action, the master calls a job that is configured to be executed on the slave, running the actual LabVIEW build script ("Execute Windows Batch Command" in Jenkins)
• The build script runs some VI Analyzer tests, handles tag / version numbers, modifies the build spec to have the version information in the .exe, and does a bit of other fancy stuff.
  • You may want to take a look at the VeriStand Jenkins-Autobuild Add-On which Stephen Barrett shared / point me to.

​All of the above works quite well already. What's next on my agenda is to get the build result (most of the times a .zip archive, created by the build script) to our release server via FTP. This would have to be another post-build action, as it has to be executed by the master. Also, what I'm still very unclear about is how to best do automatic builds for different LabVIEW versions when having source distributed libraries without block diagram in a project.

[ensegre]

and mentioned it just a few days ago here and also on the NI LAF.

 

Indeed, now that you remark, I see a couple of relevant threads there:

Automatic Build System for LabVIEW

What is your CI Toolchain?