Automated build

[patrik-hagne]

There should be a way easier way to build a new version of FakeItEasy than there is today.

The output of the build should be the following:

A zip-archive containing:

• License.txt
• Merged version of FakeItEasy.dll (FakeItEasy together with Castle.Core).
• Non merged version of both FakeItEasy.dll and Castle.Core.dll
• The dlls mentioned above compiled both for .Net 3.5 and .Net 4.0
• The dlls mentioned above both signed (using the key file Source/FakeItEasy/FakeItEasy.snk) and non signed.
• Silverlight versions (3.5, 4.0, signed and non signed, merged and non merged).

There should be two NuGet packages produced, one for the signed version and one for the non signed version.

It would be great if a release build and push could be triggered by setting a tag in git on a release branch. The tag should be the version number that should be used for the build.

There is a TeamCity account set up at http://teamcity.codebetter.com/project.html?projectId=project152

UPDATE

We've decided that initially we will just produce a signed NuGet so we can get this closed out with merging/non-merging as a separate concern in #16. If we feel we need other outputs, e.g. signed/non-signed, merged/non-merged, etc. then we can raise further issue(s).

UPDATE

As part of closing this, assuming we have consolidated down to a single build config, which should switch on the 'Report change status to GitHub' build feature as detailed at http://hadihariri.com/2013/02/06/automatically-building-pull-requests-from-github-with-teamcity/

Currently we can't use this build feature because the 3 different build configs interfere with each other, i.e. the build might pass on one and fail on another and then it's a case of most recent wins with the status update on the pull request.

[hhariri]

What are the current issues you're facing to accomplish this? Also why do you need two nuget packages? NuGet supports different binaries...

The rest can easily be automated. EasyHttp / YouTrackSharp are doing similar things to those here...except the signing..

[patrik-hagne]

Does NuGet support signed/non signed versions of the same binaries? It didn't do that earlier so I've missed that. I do know that supports different binaries for different framework versions and Silverlight.

The issues I have is mainly my own incompetence ;-) I've managed to hack my way through msbuild so far but it's turned into an unmaintainable mess and I don't know rake or any of the other frameworks.

[patrik-hagne]

I do believe we need to support signed binaries in the archive but it's not necessary on NuGet, those who needs a signed version might have to download the archive.

[hhariri]

Can you access EasyHttp or YouTrackSharp on Codebetter.com? Most of the stuff can be done with TeamCity. You don't need to put it in build scripts. Let me know if you can view the config. If not I can give you permissions.

[adamralph]

I vote for keeping the binaries in the official NuGet package signed. Unsigned NuGet packages cause no end of trouble when a consumer wants to use them in a signed project. Although I wouldn't normally sign a test project, it is necessary when making the internals of a signed target project visible to the test project.

A package with signed assemblies can be used by both unsigned projects and signed projects. A package with unsigned assemblies cuts out the latter set of potential consumers. There are hacks available to post sign stuff after downloading from NuGet but they are quite ugly and burdensome. They also tend to breakdown if the NuGet has further dependencies on other unsigned packages.

[adamralph]

I think we should press ahead with this one. I'm also keen to get a Mono build working so we can continually ensure that FakeItEasy is Mono-compatible.

I believe we need to decide on a cross platform build framework. The candidates which spring to mind are:-

• MSBuild (should work with xbuild on Mono)
• Rake + Albacore
• Sake
• Fake

I'm not keen on MSBuild. I've worked with it a lot over the years and the coding in XML is like pulling teeth every time.

Rake is a very mature and proven product which is used across the Ruby landscape. Albacore tasks are very rich and do most of the heavy lifting. Ruby is an elegant language which is naturally suited to scripting. I have successfully implemented Rake builds which work across Windows, Linux and OSX so there is a lot of potential for reuse, see https://github.com/liteguard/liteguard/blob/master/src/rakefile.rb. The downside is that there is a dependency on Ruby, but getting set up is actually quite easy, see https://github.com/liteguard/liteguard/blob/master/how_to_build.md. CodeBetter CI has all the prerequisites installed. I currently have a Rake + Albacore project building there (http://teamcity.codebetter.com/viewType.html?buildTypeId=bt834).

Sake is a very interesting project (https://github.com/sakeproject/sake). It's main advantage is that you write your script in C# so we wouldn't have to introduce another language into the mix. However, documentation and examples are a little sparse and perhaps also it's general adoption. This would probably be a fun option to implement, however.

Fake has been around for a while now but I don't know too much about it (http://fsharp.github.com/FAKE/). Whilst it's a tempting option to use for FakeItEasy purely because of it's name ;-) I think there may be a bit of a learning curve involved unless someone with F# experience can contribute (I have none).

It's clear which one is my favourite, so my vote goes with Rake ;-).

[philippdolder]

As PSake is platform dependent I'm totally fine with Rake. Though I won't be of much help in creating and maintaining the build script, yet. But I'm always keen to learn something new.
So, let's take Rake.

And let's stick with the signed package on NuGet

I think this issue is ready.

[adamralph]

Great! I think we just need to decide exactly what the output should be before the issue is ready. I'm not convinced that the ZIP archive containing everything detailed in the description is really necessary. I'd be quite happy with a single NuGet package with signed assemblies.

The merging of Castle.Core is a separate concern and is taken care of in #16. I don't think it will affect the implementation here as we can probably embed it into the project file as I've done here https://github.com/xbehave/xbehave.net/blob/master/src/Xbehave.Net40/Xbehave.Net40.csproj#L97

[philippdolder]

Yeah, I agree. We only need a NuGet package with signed assemblies

[adamralph]

I have everything working locally. I could probably close this issue tonight if CodeBetter CI wasn't down :-(

If anyone wants to give the new the build script a try locally, pull from the 2-rake branch in my fork and follow the instructions in how_to_build.md (no deep links because the branch is temporary).

To summarise, once you have the prerequisites installed, you just type rake and the solution will be cleaned, built, unit tested, integration tested, specification tested and packaged. The CI server will be executing exactly the same command.

[adamralph]

FYI the three legacy build configs have been paused whilst I test the new build config. Unfortunately the build agents lost connectivity this morning. I'll continue to monitor. If the build succeeds then we should be good to merge.

[adamralph]

Build succeeded on CodeBetter CI.

[adamralph]

I've left the 3 old CodeBetter CI build configs in place for now. They are all paused. We can delete them later when we feel ready.