v2.0.0-rc1 Release Notes

2013-11-06 00:00:00 -0800

This release is fully backwards-incompatible with 1.x because there's been a massive overhaul of its internals. The internals are now much easier to work with and I expect that there will be a lower threshold to contribute.

The public API of v2.0 is simpler. For example, have a look at the README as an example of the new API.

I recommend you start using the new version today! It's well worth the time investment; this is the version that albacore is going forward with.

Changes: Improvements

The new version is built around the fact that NuGet has become the de-facto standard of managing your .Net dependencies. It will run NuGet.exe transparently on both Windows and Mono. We develop both on Mac and on Windows at Intelliplan, so the code has been tested for over half a year already.

One improvement that you will experience, switching to the new version, is how easy it becomes to bootstrap builds of nugets; all you have to do is to give an enumerable of file paths to the #files property:

nugets_pack :nugets => ['build/pkg', :versioning, :build] do |p|
  # FileList looks at the file system, returning an enumerable:
  p.files   = FileList['src/**/*.{csproj,fsproj,nuspec}'].
  p.out     = 'build/pkg'
  p.exe     = 'buildsupport/NuGet.exe'
  p.with_metadata do |m|
    m.description = 'A cool nuget'
    m.authors = 'Henrik'
    m.version = ENV['NUGET_VERSION']

Given that you have the normal workflow of adding a new project to your src folder and inside the sln that you work with, that project will then be made a nuget of. Zero friction. Attaching the teamcity extension will ensure that your new nuget is recognized by TeamCity, too, meaning that you'll have a bootstrapped NuGet server very very quickly: require 'albacore/ext/teamcity'.

Other improvements include unified logging and a better object model behind the scenes. Also, everything is unit-tested, at 322 test cases at the moment, and counting.

Many improvements have been made to the nuget handling, to make it easier. In the end, creating nugets should be as easy as writing Gem::Tasks.new or in this case NuGet::Tasks.new, and then rake release when you want to commit, tag and push a new nuget to NuGet.org. Albacore should support both the open source workflow and the proprietary-code workflow.

Albacore has now got a very simple publish-subscribe pattern implemented which is being used to publish when artifacts are created, at the moment, but can publish any sort of event.

More changes and improvements in list-form

require 'albacore'
require 'albacore/logging'

include ::Albacore::Logging

task :my_task do
  trace { "hello world" }
  system 'echo', 'goodbye'
require 'set'
require 'albacore/cross_platform_cmd'

class TxSrv
  include ::Albacore::CrossPlatformCmd # includes e.g. #system, #mono_command
  def initialize
    @parameters = []
    @executable = 'buildsupport/TransactionServer_IntegrationTests.exe'
    # makes sure mono is there if running on linux:
  def execute
    system @executable, *(@parameters.to_a)

class RunTests
  include ::Albacore::CrossPlatformCmd # includes e.g. #system, #mono_command
  def execute
    exe = FileList['src/packages/machine.specifications.*/tools/mspec.clr4.exe'].first
    dll = 'src/ProjA/bin/Debug/ProjA.dll'
    system exe, dll

task :it_tests do
  t = Thread.new do
  # run tests here

As you can see, there have been many changes and improvements aiming to make albacore a much nicer library to include whenever you have a .Net project that needs building and packaging.

Other changes, contrasted with master branch

The improvements aside, there are structural changes to the rewrite, too:

The road ahead

A little about where Albacore is headed.

Configuration and VaryByParam

In the README for this release, I have documented one feature that has been rebuilt by albacore consumers many times over; building with multiple frameworks -- e.g. constructing a build task-type and having it run once with .Net 3.5 and then a second time with .Net 4.5, executing the full task-graph every time.

Having a configuration that does 'vary by param' would make this type of build-per-parameter-combination much easier to perform.

Representing the tasks as a graph

In v3.0 I want to have refactored Albacore.create_task and all task-types in the DSL to construct an immutable graph of things to build. Only after constructing the immutable snapshot (specification) does the build commence by starting to call the tasks' #execute.

This would make the build much more declarative and make interop with project like repobuild easier to program.

Besides, it would allow a much higher degree of modification by extensions, by letting each task (created through a task-type-method in the DSL) carry with it its Config and description and list of dependencies. This graph of tasks could then be fed through a pipeline where each extension can inspect and possible output a new/changed graph, should it want. Since the graph is directed, acyclic, the vary-by-param task could then be implemented simply as a task that takes its child trees (child tasks) and duplicates them, having all child tasks take properties of the Config of the Vary-By-Param task as DependentVariables.

Improving deployment

In v3.0 I want to have a deployment example for Linux and mono with proper versioning and artifact management. Simply put; everyone needs to deploy their systems, and if the build system can help you or recommend you how to do that, it's a gain. Work items such as #54 come to mind, something that should dovetail nicely with a v3.0 release of albacore.

Improving testing

For .Net developers in general, starved half to death of good testing tools (albeit excellent tooling for unit-tests in particular, not much after that), having a build system that makes it easier to test code, could be invaluable. Just as nugets_pack allows you to bootstrap your nugets very quickly, integration with for example tsung or suave would make it much easier to test your web code.

The aim of albacore, hence, isn't to force these tools on you, but rather to provide a runtime that can be used on a CI-server that keep the tools in check, configuring their runs, running and monitoring the processes and then collecting their results.


I'm really happy to have gotten this release out of the door, so test it. Around new-year I plan on doing the RTM v2.0 release unless something comes up.

Happy coding! Henrik Feldt

blog comments powered by Disqus