How to better split FAKE build script for Teamcity

Question

Without Teamcity I would put everything into one big .fsx script and just "fire and forget" it. It would be OK to have a single script for the build, doing all the work.

But when we put .fsx script into Teamcity, everything changed. Teamcity has nice build log and build steps features, but putting all logic into the same script and build step resulted in HUGE build log.

We have build and tests in a single .fsx script, and I was going to place distributive building into it either. But now I don't think that this is a great idea. Perhaps it would be better to split this build script into several build scripts and run them in several build steps?

But with several scripts it's not too convenient to run build locally, without Teamcity if we need to. Or we can have several small build scripts for every task ans one build script for the local build calling all these small scripts.

What is the best solution for this?

Answer 1

This is my personal opinion and not a "best solution": I would not use multiple build steps or build pipelines in Teamcity since this will lead to vendor lock in.

That said if you still want to use build pipelines then use a single build file and make heavy use of FAKE's build targets and conditional dependencies.

if isLocalBuild then
  A 
  ==> B
  ==> C

So you can still run it locally like before. In TeamCity define a build pipeline which calls only one target in every build step (using FAKE.exe target=A).

Answer 2

Well, I suppose I've done something similar to @forki23 suggestion. I've put everything into a single .fsx, defined several target's chains not related to each other, like this:

Clean ==> Build
BuildTests ==> RunTests
SignExes ==> PackDistr

and on each build step I call one "leaf" target, i.e.

Step1: fake build.fsx target=Build
Step2: fake build.fsx target=RunTests
Step3: fale build.fsx target=PackDistr

Locally, I created several .bat files for building locally, and I've defined target's call order in these .bat files. But I suppose it would really be better to use the isLocalBuild value as @forki23 suggested. This would make build logic more encapsulated into single .fsx script and that's great!