Hi Support Team,
our build has a text varible, which a user can set immediately after the ‘queue a build’ button is pressed. The variables value is displayed with the content defined in the configurations variables section.
The user changes this value. This new value should be displayed in case the build is started the next time. I have not found any way to achieve this; the ‘Queue Options’ page always displays the default value of the variable.
We had the same problem using FinalBuilder Server, and I was told (some years ago) that ContinuaCI will provide means to solve this. Do I oversee something or is this still not possible?
Best regards
Michael
Hi Michael,
We don’t currently have any facility for storing variables between builds, but do plan to implement some functionality to do this.
It would be interesting to know what your use case is for this. We have had several requests for persisting variables. Generally this is for storing the values of variables set during the build. The issue is that builds can run concurrently and it can be an issue of timing as to whether a build can pick up a variable stored by a earlier build. Storing the values entered at start up should however be less prone to this issue.
We have been discussing adding options to the variable editing dialog - one to persist values on build start and another to persist at build completion. We don’t have any timescales but it is a relatively high priority item on our to-do list.
Hi Dave,
Thank you for your reply. Our use case is as follows:
I create a project / configuration to compile / build our software. Lets say, we currently build v2.15.0. Any time the build is started, the build number automatically increases. So there is no need to influence the version number - the software version will be for example 2.15.0.123, 2.15.0.124, … That’s fine so far.
Consider we want to build a 2.15.1 bug fix release. Now we have two options: clone the configuration or providing means to specify the release number on start of the build.
I don’t like to have lots of (nearly) similar configurations. I prefer the latter option and have added a variable for the release version. This appears in the “Queue Options” dialog after pressing the ‘Queue’ button. If this field is left empty the most recent used release number (2.15.0) will be used for the queued build. If not than in a first stage the ‘Set Build Version’ action updates the BuildVersion to the entered value (in this example to 2.15.1).
Using this approach the “Build #” is ‘wrong’ during the first stage. But this stage is kept small / short. This is not be an issue. More disadvantageous is that the user cannot see whether or not he HAS to enter a new release number because there is no option to display the release version which will be used on the “Queue Options” dialog. The only way is to look at the “Recently Completed Builds” for the latest “Build #” before the ‘Queue’ button is pressed.
I hope this information is somewhat worthful for you… 
Best regards
Michael
Hi Michael,
Thank you very much for posting a full description of your use case. We can see how it would be useful to have more than one build number. We use a different configurations for each release type e.g. Release, Beta, Development with each incrementing it’s own build number. The issue with this scenario is that we then have to maintain changes across configurations.
I’ll increase the priority on this feature, although we currently seem to have a quite lot of high priority features in our to-do list!