Auto-increment build number

[Dhakkan]

Hello All,

My colleagues and I are new to continuous integration. Thus far, we have successfully been able to configure Bamboo to poll a specific Bitbucket-hosted git branch, perform a build using LabVIEWCLI and alert success or failure via email. The build number of the resulting executable, however, does not auto-increment, even though the setting is selected in the project's build specification. (To be expected, I guess, since the *.lvproj file is not modified by the LabVIEWCLI process.)

We tried the available LabVIEWCLI documentation and other online forum searches; but couldn't find anything specific to perform an auto-increment. An old (2009?) post with a similar question had a negative response.

As of now, we are planning to use the a Bamboo script to

1. Track the build number (not sure where.. a file?).
2. Update the *.lvproj file's build number using either PowerShell or equivalent scripting
3. Perform the build.
4. Update the new build number within Bamboo upon successful build.
5. Revert the *.lvproj file (unnecessary?).
6. Tag the last commit with the new build number and push the tag to Bitbucket cloud.

We would like to avoid manually updating the build number in the build specification. (The major, minor and patch version will however be manually controlled.) After step 2 above, we thought we would commit the *.lvproj file with the new build number - however, that could lead to an infinite build cycle since the Bamboo server would be notified of a new commit...

Any opinions, recommendations or suggestions on this would be much appreciated. Thank you.

[Nathan-M · Accepted solution]

In the Application Builder API there are two VIs - Get and Set Build Specification Version. You can call these VIs from LabVIEWCLI with the right project path, build spec name, and your desired version number. This should be done after the source has been copied, of course. 

You can use your CI system to track the version number and apply it to the project file at the time of building.

This does have the downside of the project file not being in sync in your SCC, so it may be worthwhile to commit the project file back once modifying the version number. That could get tricky though, just to avoid having another build kick off. 

[cbutcher]

I suspect others will offer better solutions, but one option would be to have the commit after build have a specific message format (that would be pretty easy, since you'd already be generating it) then check the commit message against a specific pattern when triggering a build.

If the new commit has a message like "Committed following build A.B.C.newD" then skip the build and notification steps.

[Nathan-M]

Yeah that's one option. I think it would probably be best to do it on a user base. This way here any commits from user 'build-machine-001' do not cause a new build to occur.

[Dhakkan]

Thank you! Nathan and cbutcher, for your super-quick and helpful responses.

Nathan, by '...best to do it on a user base', do you mean that the CI tool could be scripted to conditionally kick-off the build process only if the commit was not done by the CI-tool's git credentials? If so, that would certainly be enough to tackle the SCC out-of-sync situation; and preclude the infinite cycles of build kick-off.

I shall try the options you both suggested and post back our findings.

[Nathan-M]

---

@Dhakkan wrote:

do you mean that the CI tool could be scripted to conditionally kick-off the build process only if the commit was not done by the CI-tool's git credentials?

Yup! That's exactly what I mean. 

[cbutcher]

I'd definitely recommend the user based testing over string pattern matching!

As predicted, someone offered a better solution 😉

Just be careful if by some peculiar chance your pipeline or flow depends on the CI tool committing something to intentionally trigger something else (but it shouldn't, probably) 

[Dhakkan]

Awesome! Nathan. Marking your response as the solution.

Cbutcher, noted your caveat and agree.

[Nathan-M]

Happy to help! If I can save one person the pain of trying to parse the project as an XML file and writing all sorts of wrapper VIs to update versions... 

That's where I started a couple months ago, at least, before I came across the VIs I pointed you to. Don't know why it took me as long as it did to just search in quick drop for 'build spec'  

[tyk007]

Wrapper VIs around reading / writing the project xml tags is still useful for older versions of LabVIEW - the Build Spec VIs were only added in 2014 and a lot of my legacy projects are in 2013/2012.