We have been using Finalbuilder/Finalbuilder Server 7 for quite some time now and are evaluating moving to ‘Continua’.
Part of our existing build requires making modifications to some VS project files before they build so that certain internal steps like ActiveX registration
can be skipped. Within the Finalbuilder build project we would manually svn revert those changes before performing an svn update and then strip
the VS project files again (so that they are otherwise always up-to date).
We are curious as to how this would be handled with ‘Continua’ since its now handling the repository. How does ‘Continua’ handle changes
to the repository? Will it continue to update these VS project files if they are modified by the Finalbuilder project (which we have stripped the repository
related actions from)?
Hope that is clear enough!
Simon Kennedy
Hi Simon, thank you for posting.
Continua uses a clean version of the source at the start for every build. From my understanding of your process this is good news as you should no longer need to undertake the svn commit / rollback process going forward with Continua.
Continua has the concept of a workspace (which you can use to undertake any manipulations before / after the build as required), further reading about this can be found on the wiki: http://wiki.finalbuilder.com/display/continua/Build+Workspace
Thanks
Thanks Peter,
That raises the question for us as to how ‘Continua’ performs with that in mind as the reason why we reverted/update rather than simply deleting and re-checking out was to save time. We would like to keep build times down, especially incremental builds, so that developers get feedback as fast as possible (currently incremental builds are ~20 mins).
I guess we will see what impact this has as the evaluation continues.
Thanks,
Simon Kennedy.
Hi Simon, Continua has many smarts to help out in this area.
One of these features is Continua’s repository cache which keeps Continua up to date with the underlying repos automatically (highly configurable). Initialising builds is usually a very cheap process. In the case of very large repos we have features such as monitoring specific branchs etc (http://wiki.finalbuilder.com/display/continua/Repositories).
Always happy to discuss your performance experiences, reach out to us here or email support@finalbuilder.com Thanks.
Hi Peter,
Does this mean though that we cannot do an incremental build in the sense that the binaries, object files cannot be retained between builds and that thosese files must be recreated each time (unless they can somehow be specified as artifacts)?
Thanks,
Simon Kennedy
Hi again Peter,
I just wanted to add that after performing several builds on the same configuration the sync time to the agent before the actual build starts is around ~12mins. This is about the time it would take to download the entire source! We only have one repository on the ‘/trunk/’ branch.
Is there any way to see what its actually syncing and why?
Simon Kennedy
Hi Simon, thank you for posting.
In order to look further into this one could you please send us (support@finalbuilder.com) some further information about your setup:
- The output of the following (powershell) command: ([xml](svn list --xml --recursive https://PATHTOYOURSVNREPO)).lists.list.entry | measure-object -sum size
- Within the stage edit options could you please enable workspace logging, and repository logging, run a build and send us a copy of your build log (this may give you a better idea of what is taking time).
– Any large folders within the repocache \localhost\continuashare\Rc ?
– What version of Continua and edition (eg 1.5.0.343 64 bit?)
– Local agent?
– Which version of Windows are you running
– Which database platform are you running
– Diskspace / RAM / other resources on the server?
I’m not having any success with the powershell command (its new to me)
If I try [xml](svn list --xml --recursive https://PATHTOYOURSVNREPO)).lists.list.entry
it does not print any thing (I confirmed that just the svn list command is producing XML).
Simon Kennedy
No worries, in my case I typed the following command (all on one line):
([xml](svn list --xml --recursive file:///i:/testing/svn-fun/trunk)).lists.list.entry | measure-object -sum size
and got the below output:
Count : 12
Average :
Sum : 86
Maximum :
Minimum :
Property : size
in your case you may be using http / or https etc
I figured it out the [xml] cast requires outer brackets!
The returned value is 255626084 or 255MB!
At least 50MB is due to the Help files being included. We would normally not include that but I have not figured out how to filter this out within the repository configuration.
I’ll move on to collect the rest of the information.
Thanks,
Simon Kennedy
Does this mean though that we cannot do an incremental build in the sense that the binaries, object files cannot be retained between builds and that those files must be recreated each time (unless they can somehow be specified as artifacts)?
We do not currently have the ability to do dependencies between configurations (or chain configurations together as part of a single build).
We do however have stages within a configuration. For example stage 1 might build a specific project, stage 2 might build another project, stage 3 might test both projects etc. Via the stage options dialog you can configure which repos are sync'ed to agents within each stage if required.
Any outcomes from a build can be added as artifacts (however as mentioned above these artifacts cannot be used as an inputs into another configuration).
This is a feature we plan on implementing and is on our list of considerations going forward.
Hi Simon; additionally would you be able to send a full debug log for a build when you get a chance (http://wiki.finalbuilder.com/display/continua/Debug+Logging)
Thanks again
More information:
- Any large folders within the repocache \localhost\continuashare\Rc ?
There are three folders; two of which are ~680MB, the other is only ~200KB (probably the original configuration with no source)
– What version of Continua and edition (eg 1.5.0.343 64 bit?)
Yes, I’ve just installed Continua Server 1.5.0.343 64 and a single agent of the same version
– Local agent?
No, the agent is installed on our original finalbuilder VM so I can evaluate actual builds (I got a eval license for the purpose).
– Which version of Windows are you running
Windows Server 2012 Datacenter 64bit
Installed in a 64bit Hyper-V VM
– Which database platform are you running
We used the default postgres option from the install.
– Diskspace / RAM / other resources on the server?
4GB Memory
Diskspace - 113GB of 126GB free.
Hope I have not missed anything!
If we could persist artifacts across builds then we could solve our main issue. Our current build process goes something like this:
*) Check if First Solution has been modified
Checkout source for First solution
Build first solution
*) Always build Second solution (because source code in either solution may have changed)
Checkout source for Second solution
Copy binaries from first solution to second solution
Build second solution
Build installs, etc
With our existing solution we can skip building the first solution if nothing has changed but we do
require that the binaries exist as they are dependencies of the second solution.
We also do not clean the solutions for incremental builds so we can also reuse the obj/lib files which also saves a lot of time
(we accept the small risk of VS getting it wrong but that has not occurred enough to bother us).
We could copy the binaries to some temp location on the build server but it still leaves issue of not being able
to reuse obj/lib files which I think might be the killer for us.
Hi Pete,
Do you have a timeframe for when support for incremental builds like this would be available?
Thanks,
Simon Kennedy
Hmmmm, could someone give me an idea of how long a sync should be expected to take for a ~200MB repo that has not been modified?
Hi Simon, Im sorry I cannot give any firm estimates on delivery of this feature, it is something we want to build and its on the list of items we are working through. We are working on several other high priority items at the moment and aim to move onto an answer to these use-cases shortly.
In regards to the time taken to sync, we are awaiting a build log in order to determine what is taking the time on this one (please send to support@finalbuilder.com). In our testing its quick (< 30 secs) to sync to the agent for a 200meg repo across a 100mb LAN link (under UNC).
Thanks.