Replace Continua CI's versioning with value produced (by FinalBuilder 8 or in general) during the build?


We are in the process of migrating from FBServer+FB7 to CCI+FB8
FB8 is still our main build runner, our FB8 (converted from 7) projects are rather complex and take care of 100% of the build and deploy processes, including versioning.

Currently when I test builds via CCI+FB8 it seems CCI versioning is mandatory (either per project or per configuration).
Alas these version numbers are meaningless to us, our REAL version numbers are produced during the FB8 project run.
Can versioning be disabled completely or setup to be overridden by values produced by FB8 during the build?


In Finalbuilder 8 there are some Continua CI actions - one of which is Set Build Version - this outputs a formatted message that Continua CI understands and will update the build version in Continua CI.

1 Like

Thank you Vincent!
The only problem we have with this is - when running the build always still starts with version 1.0.0.XY Which is taken from Continua CI’s Internal versioning mechanism, and only later some time during the FB8 project run time - this gets updated to the correct version information provided by the FinalBuilder action.
Since this can be some what confusing - is there a way to completely disable Continua CI’s versioning for specific projects or configurations and only display it if updated externally (from FB8 in our case)?

We ran into the same problem. We changed our “Version Format String” under a Configuration | 1. Details to “Starting $Build.BuildNumber$”

This removed the confusion.

1 Like

Robert’s answer is what I would suggest.

There needs to be some text to display for the build version, but this can be anything.

You can set the Version Format String to “-” to be minimal, but it’s better to set it to something unique as suggested by @rlove.

The initial version (before the Version Format String gets set) is the same as ‘# $Build.BuildNumber$’. Another option would be to use the time e.g. ‘Created $Server.Now.ToShortTimeString()$’

If I use “Starting build…” as our “Version Format String” -
It works great for good builds where the underlying FinalBuilder 8 project uses the “Continua CI - Set Build Version” to set the correct version on Continua CI.
(It updates from “Starting Build…” to whatever FinalBuilder 8 sets the version to)

But if the FinalBuilder 8 project fails BEFORE reaching that action -
The text remains “Starting build…” and only changes to show a red background color.

I have resolved this by adding another stage that triggers only if
$Stage.IsSuccessful$ does not equal “True”
And adding “Set Build Version” action to that stage that updates the Version format string to “Build Failed!”
That works, but this text (“Build Failed!”) shows in green because the the build actually completed successfully (the main stage that is running finalbuilder 8 - failed, but the “OnFailure” stage that came after it - obviously completed succefully)

I did not see a “Set Build Status” or other equivalent actions (“Fail Build” ?) in Continua CI:
Could you guys possibly allow the “Set Build Version” Action in Continua CI to have a “Build status” option that would indicate the build status, and color the “Version” in all screens accordingly?
If not - any other solution would be appreciated!

I tried to solve this by adding an action that will 100% fail in the “OnFailure” stage.
This way the “OnFailure” stage will always finish with an actual failure and the version color will be red.
I used a “7-Zip Extract” action that is set to extract a file that does not exist.
Alas this results with good builds “Version” being colored in red since the “OnFailure” - always fails… and the build status is reflecting the final result of running all stages and not just the “FB8” stage.

Bottom line is: I can use my mentioned solutions above and get “Build Failed” text on failed builds and a real Version number on good builds - but the color indicating build status is wrong this way.

Hi @ktopaz,

You can fail your “OnFailure” stage using a Stop action set to ‘Stop stage and build as failure’:

Surely with your $Stage.IsSuccessful$ does not equal “True” condition the “OnFailure” stage only runs when the Finalbuilder action fails, so I don’t see how the “good build” would be coloured red?

Instead of adding a new ‘OnFailure’ stage, you can wrap the FinalBuilder action with Try and Catch actions. Add your Set Build Version and Stop Action under the Catch action. e.g.


This will have the advantage that the actual stage that failed will show as failed.

Note that could done similarly using the Try, Catch and Stop Build actions in FinalBuilder.

When using the extra “OnFailure” stage and having the first stage successful - the entire build evaluates as not successful because the gate to the next step is failing its condition
“$Stage.IsSuccessful$ does not equal “True”” - this evaluates to false and thus:

“The following Stage Gate Condition failed:
The expression [’$Stage.IsSuccessful$’ does not equal ‘True’] evaluated to False. ‘True’ equals ‘True’.”
Due to this message - The “OnFailiure” Stage Gate Condition failure to match the previous stage `$Stage.IsSuccessful$ to True - The entire build seems to be marked as failed.

But regardless of that, I am trying to use try-catch instead of a separate stage as you suggested because this idea does seems more logical to me - but there’s something strange going on:

Under “catch” I set the build version format string to “Build Failed!” and set a “FinalBuilderFailed” variable to “Failed” and just below that (outside the “Catch” clause) -
I have an if condition to check if indeed “FinalBuilderFailed” variable evaluates to “Failed” - if it does - then it runs a “Stop” action that should mark the stage and build as a failure.

What actually happens is:
FB8 Run fails (I cause this deliberately by passing a non-existing git branch to FB8 to deploy from)
The “Build Version” is updated to “Build Failed!” (as expected, 1st nested command under “Catch”)
“FinalBuilderFailed” variable is set to “Failed” (as expected, 2nd nested command under “Catch”)
If clause checks if “Failed” is listed under “FinalBuilderFailed” variable and if so calls “Stop” action which is set to “Stage and build as failure”

BUT the “Build Version” (the same one that says “Build Failed” is in green… because somehow the build evaluates as successful even though the “Stop” action should have marked both stage+build as failures.

attaching screenshots of the stage setup and of a failed build to illustrate:

Hi @ktopaz,

Sorry, didn’t I realise when you wrote

that you were talking about a gate condition. If the gate conditions are false then the build fails, so I can see why this would not work in your scenario.

I suspect that you stage gate no longer includes the default condition: "$Stage.IsSuccessful$" Equals "True". If this condition is removed, I see the same behaviour as you.

However the Stop action set is to “Stage and build as failure” so really the gate condition should not matter, the build should fail before evaluating the gate conditions.

Thank you for reporting this - it appears to be a bug, and we are now investigating a fix.

1 Like

Thank you, That was indeed my scenario - after removing the “OnFailure” stage earlier I’ve removed all stage conditions
I only have 1 stage at this point (to call FB8) so I didn’t think it would matter but I see now that this has further implications, anyway - nice catch! I’ve added this condition again and now it works as expected.
Looking forward to seeing your solution/fix in regards to the “Stop” action in an up & coming release!

Hi @ktopaz,

Version includes a fix for the Stop action

1 Like