Continuous Integration

Highlighted

CI Build Versioning

Does anyone have a best practice on how to properly version your application exe build when using CI?  I'm planning to have my application built into an exe and also creating an NI Package for it using CI, but can't figure out a good way to set the versioning.

 

Currently, we've got the build script triggered by a commit to the repo.  Is there some way I can pass in the build number at that point in time?

0 Kudos
Message 1 of 5
(239 Views)
4 REPLIES 4
Highlighted

Re: CI Build Versioning

One common way of doing this is to tag the commit and then read the tag back when building. 

 

We use gitflow for triggering our Release Automation Tools. The name that is given to the release (we adhere to semantic versioning) ends up as a tag, and the that is later written to the .exe or source distribution.


An opportunity to learn from experienced developers / entrepreneurs (Fab and Steve amongst them):
DSH Pragmatic Software Development Workshops

Joerg Hampel (CLAChampion) | Hampel Software Engineering (Center Of ExcellenceDQMH Trusted Advisor, ALA) |  WUELUG
Message 2 of 5
(225 Views)
Highlighted

Re: CI Build Versioning

How are you distributing the application? Are you automatically deploying the application from your CI system? If not, manually create the application that will be deployed and manually set the version or use a process that you had in place before. For CI systems build, does it matter what the build version is? Are you tracking that for each CI build?

 

If deploying from CI most systems have a way to set variables. You can pass set the build version number with the LabVIEW Application Builder API. You can use G-CLI to send command line parameters.

0 Kudos
Message 3 of 5
(224 Views)
Highlighted

Re: CI Build Versioning

I'm using the commit message that triggers a build to determine what the "type" should be (Major, Minor, Patch) and then incrementing via git tags.

 

This works fairly nicely but one thing to be aware of is you can't version multiple things from the same repository, for example if you have two libraries in one repo and are building PPLs, they won't be able to be separately versioned with this method.

 

You could also consider a file alongside your source code holding the text value for the version and incrementing this, but then you have to commit the file back as part of the build and so your commit hash that triggers the build could be (depending on timing of commit) either a) different to the commit you build or b) one commit behind the latest commit after the build, meaning you'd tag a commit that doesn't have the file updated for the version. These are why I opted for directly using git tags.

0 Kudos
Message 4 of 5
(204 Views)

Re: CI Build Versioning

This question sounds similar to:

https://forums.ni.com/t5/Continuous-Integration/Auto-increment-build-number/gpm-p/3867117?profile.la...

 

I've since created an Operation for the LabVIEWCLI that you can call from CI to set the build spec version number per build spec. It's effectively just a wrapper around the Application Builder API Set Build Specification Version. You can also use the LabVIEWCLI with the ExecuteBuildSpec operation to build an NI Package, and as part of the Package spec you can specify which feed to publish it to. That's how we do it, at least. 

 

Edit: To more directly answer your question, we have a plugin in Jenkins that generates version numbers based on our own versioning schema and use our own LabVIEWCLI operation to set the build spec to that version string. 

Nathan Murphy
Certified LabVIEW Architect
0 Kudos
Message 5 of 5
(199 Views)
Reply
This is an open group. Sign in and click the "Join Group" button to become a group member and start posting.