Getting the build number in a plugin


#1

I’ve been using the following Objective-C code in a Mac standalone app to get the build number from the app bundle:

NSDictionary* infoDict = [[NSBundle mainBundle] infoDictionary];
NSString* buildNumberString = [infoDict objectForKey:@"CFBundleVersion"];
return buildNumberString.UTF8String;

Obviously this does not work in a plugin! As the bundle is the host… is there any way to retrieve the build number in a plugin?


#2

There’s a build number?! :slight_smile:

We just some magic to insert the git commit id into all our builds… dunno if that’s any use :slight_smile:


#3

I’ve considered doing the git commit number directly into a header file thing too - currently I have a pre-build script that updates the Xcode build number with the number of git commits. I should probably change that to insert the number into a header #DEFINE


#4
const String szVersion (JucePlugin_VersionString);

??

Rail


#5

I think there’s ProjectInfo::versionString or something which works for non-plugin projects too…


#6

I think that outputs the version number, e.g. 1.2.3; I want an auto-incremented build number that I don’t need to think about, and only update the version number for releases.

I have something that works from the command line but not from the Xcode pre-build shell script:

# Set the build number to the count of Git commits
buildNumber=$(git rev-list HEAD | wc -l | tr -d ' ')
sed "s/GIT_BUILD_NUMBER.*/GIT_BUILD_NUMBER $buildNumber/" "${PROJECT_DIR}/../../JuceLibraryCode/AppConfig.h"

In my AppConfig.h user code section I have

#define GIT_BUILD_NUMBER 0

#7

Ah - yeah thats more or less what we do … only we do it on the build server using some python prior to doing a commandline (automated build).


#8

Setting up a build server is on my list of daunting things I should really do…!


#9

It was horrible. If you’ve got a single command end-to-end build already you have about half of the problem done :)… We used Jenkins - it’s great once configured. Maybe a day to get working if you’ve got a script already…


#10

But now it’s working it’s been reliabley building Mac and PC for about 3 years now with no maintenance really, and it builds remotely on my Mac at home from the office… phat that is :slight_smile:


#11

we have just simple shell/batch scripts running sub scripts doing everything including fetching the git rev similar to above suggestion.

so yeah, it can be used by a build server but it also works just fine on any developer machine.


#12

As said above having a script do everything is half the battle when it comes to CI. If you can build in the cloud I suggest checking out Travis as I hear it now does all three platforms (https://blog.travis-ci.com/2018-10-11-windows-early-release). If you want to setup build machines (or better still VMs) then I recommend GitLab either self hosted or in the the cloud, obviously in the cloud is more hassle free (https://about.gitlab.com/). If you want a combination of both, Azure for DevOps might be worth a look, although it’s not free to run builds in the cloud (https://azure.microsoft.com/en-gb/services/devops/ Azure pipelines is the bit you should be most interested in). Certainly in the case of Travis and GitLab you will have a much easier and quicker time setting them up than you likely will with Jenkins.

Back to the original point, the jucer file can have a fourth number laid out like so 0.0.0[0] I suggest the forth number is not a git revision but instead a build number produced by your CI system (travis, gitlab, azure, jenkins, etc.). The reason being is that from this number you will be able to get back to everything and see not just the git revision but the logs and all the artifacts produced such as a crash symbolication file for example. You can set the version number from the command line, save it on your repo as 1.2.3[0] then call --get-version using the projucer and search are replace [0] before calling --set-version. The CI systems will set the build number as an environment variable, so have your script only replace the number when the environment is there or what I’ve done in the past is added an argument to my build script --build-number I default it to 0 so that’s what local builds use and on CI systems I call my script with the argument like so
build.py --build-number CI_BUILD_NUMBER_VARIABLE

One other point to make is that forth number in the jucer file is not used in the version numbers reported to hosts (in most cases at least) so make sure all public builds have at least one of the other numbers bumped before release or a host might not realise it’s changed from one version to the next.


#13

Just FYI: if you use Jenkins, it has a build number in the environment, that you can reference in your script as env.BUILD_NUMBER. It is per project/branch and will automatically increment. It is not changed, when you delete a build.


#14

To be clear this should be true for just about any reasonable CI system, for example…