Continuous Integration

cancel
Showing results for 
Search instead for 
Did you mean: 

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?

Steven Dusing
CLA, CTA
0 Kudos
Message 1 of 5
(4,206 Views)

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.




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


Message 2 of 5
(4,192 Views)

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
(4,191 Views)

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.


GCentral
0 Kudos
Message 4 of 5
(4,171 Views)

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
0 Kudos
Message 5 of 5
(4,166 Views)