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.
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)?
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.
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:
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.
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!
