-
Notifications
You must be signed in to change notification settings - Fork 18
Home
A convention driven set of build scripts for .net projects. It was created after we gave up on trying to tame MSBuild. We use NUnit for unit tests, SpecFlow for BDD and publish our artifacts via NuGet.
So by default, that's what Build.Tools does too.
Check out the overview at http://15below.github.io/Build.Tools
We pull this repository into other repositories for building using Paket GitHub dependencies
By adding this dependency, you automatically (though paket magic) get FAKE.
Assuming the paket bootstrapper is in a .paket folder & your solution file is in the root of src, you can then have a build script which contains:
.paket\paket.bootstrapper.exe --run restore
packages\FAKE\tools\FAKE.exe paket-files\15below\Build.Tools\Core.fsx "solution=src\MySolution.sln"
Running the batch file will carry out all of the operations above, except publishing NuGet packages; you'll need to give it a bit more information for that.
Of course, see Changing the default build process for more information.
By default, it will only publish at all if it is running on a build server (tested on TeamCity, others should be detected in most circumstances).
As well as running on the build server, you will also need to supply the following configuration values either on the command line or as environment variables. We would recommend the latter in most cases.
- pushto - either dir or url
- pushdir - push files to a directory / UNC path
- pushurl - push files to a nuget feed
- apikey - api key for the nuget feed
Finally, Build.Tools will only attempt to create packages from projects that have a matching .nuspec file in the same directory as the proj file.
For example, if you want to package My.SuperLib.fsproj
you'll need to put My.SuperLib.nuspec
in the same directory. NuGet.exe can help you generate the nuspec from the project file using the spec command.
We use feature branches heavily, and don't want to get them confused with release branches. We assume a release build is a build built on the build server, on the master branch of a git repository.
As such, if your project's assemblyinfo file contains an AssemblyInformationalVersion and any of the above are not true, Build.Tools will create a pre-release NuGet version with a name based on the branch name.
Write them in NUnit and call the dll [something].Tests.dll. Patches and conventions for other test libraries accepted.
If you are using nuget, we'll try and pull down the NUnit test runner automatically. For Paket, make sure you add NUnit.Runners to your paket.dependencies to take full advantage Paket's rapid restores and sensible version management.
Put them in a dll called [something].Features.dll.
Sorry, we don't support that yet. Why not send a patch?
There is opinionated support included for generating Octopus deployment packages, see Deployment.
They're F# script files. F# was added to the official .net family of languages in Visual Studio 2010, and part of the language is a specification for script files. The ones in Build.Tools are designed to be run via the FAKE (F# make) executable, but Visual Studio will recognise them as valid F# and you can edit them with full intellisense support and type checking.
FAKE (F# make) is both an executable wrapper around F# interactive, and a set of helper libraries that can be referenced from fsx scripts (or any .net code, for that matter). The scripts in the Build.Tools project are designed to be run by FAKE which provides things like timing metrics and target dependency resolution. A specific version of FAKE is included within the repository so that you can just sub-module it and go without having to worry about dependencies. You can check out the FAKE project pages if you want to know more.
Probably not. The NUnit and SpecFlow runners assume they are running on Windows at the moment. Patches to make the scripts Mono compatible would be gratefully accepted.