v0.0.8 Release Notes: More Rake-ish Than Ever!

There are a significant number of changes that have gone into Albacore in the last few weeks. Everything from new tasks and functionality, updated syntax for the tasks, and bug fixes, too.

Albacore Task Syntax Changes

There was some discussion on the google group surrounding a peice of functionality that we decided to leave out. However, the result of the discussion was the realization that the syntax of the Albacore tasks did not match the built in rake tasks, such as “task” and “file”. As a result of this discussion, we’re making things more ‘rake-ish’ for the task usage. After all, that was one of the original goals right?

The end result is a new shortcut syntax that allows you to do this:

msbuildtask do |msb|
 msb.solution = "mysolution.sln"
 #... other settings here
end

Youc an do this with any task… so, Albacore::AssemblyInfoTask.new is now assemblyinfotask do ... end, Albacore::NCoverConsoleTask.new is now ncoverconsoletask do ... end, etc.

The old syntax still works, too. However, you are now required to pass a task name into the .new constructor. For example, you can still call Albacore::NCoverConsoleTask.new(:ncoverconsole) do ... end. The default names have been moved to the new syntax shortcuts, and out of the old tasks.

Additionally, with the new syntax shortcut, you don’t need to specify Albacore:: and you don’t need to speify the .new initializer. You can just call ncoverconsoletask or assemblyinfotask directly.

Supporting The Complete Task Syntax

In addition to the new syntax shortcut, the complete rake task syntax is now supported by all Albacore tasks. This means you can take advantage of the task parameters and dependencies when you want to, like this:

msbuildtask :msbuild, [:config] => :assemblyinfo do |msb, args|
    msb.properties = {:Configuration => args.config}
    #... other settings here
end

and call it with rake like this:

  rake msbuild[Debug]

The new syntax let’s you do any valid combination of the “task” syntax…

msbuildtask :name => [:dep1, :dep2, :etc] do |msb| ... end

msbuildtask do |msb| ... end

msbuildtask :name do |msb| ... end

msbuildtask :name, [:param, :param2, :etc] do |msb, args| ... end

msbuildtask :name, [:param, :param2, :etc] => [:dep1, :dep2, :etc] do |msb, args| ... end 

Nunit, XUnit and MSpec Tasks

These have kind of, sort of been around for a while now. They are partially in the .7 release, but are officially first class citizens of the .8 release.

From the rakefile, here are some samples of the new tasks:

NUnit Task

desc "NUnit Test Runner Example"
nunittask do |nunit|
	nunit.path_to_command = "NUnit/nunit-console.exe"
	nunit.assemblies << "assemblies/TestSolution.Tests.dll"
end

XUnit Task

desc "XUnit Test Runner Example"
xunittask do |xunit|
	xunit.path_to_command = "XUnit/xunit.console.exe"
	xunit.assemblies << "assemblies/TestSolution.XUnitTests.dll"
end	

MSpec Task

desc "MSpec Test Runner Example"
mspectask do |mspec|
	mspec.path_to_command = "MSpec/Machine.Specifications.ConsoleRunner.exe"
	mspec.assemblies << "assemblies/TestSolution.MSpecTests.dll"
end

Generic Command Execution Task

As a way to help people use the built in logging and auto-configuration capabilities of Albacore, a generic CommandTask has been added. This task will allow you to run any arbitrary command, with parameters, from your rakefile.

As a contrived example that illustrates how it works, here is how you could run the nunit console app with a —help parameter to get the list of options.

commandtask do |cmd|
	cmd.path_to_command = "tools/nunit-console-x86.exe"
	cmd.parameters << ["--help"]
end

Include Files For Expand Templates Data

Several users requested the ability to have a “global” data set for the expand templates task. This would allow common data across all environments to be set up in a single location. After some thought, a new @include: filename.yml directive was added to the expand templates task. This will allow you to reference an external yaml file and have the contents of that file included in the data that is used for the expansion.

You can override the external file data by including specific key / value pairs in your regular data file. This works for both simple key / value pairs, and for template specific data.

An extended example

If you have a template, such as this:

web.config.template

 <appSettings>
	<add key="name" value="#{value}" />
	<add key="another" value="#{setting}" />
 </appSettings>

You can provide some data in a web.config.yml file and some data in an external global.yml file, like this:

web.config.yml

@include: global.yml
value: this is goes where the 'name' is

global.yml

another: setting goes here.
value: you won't see this. it's overriden by the web.config.yml

You can use the global.yml or the web.config.yml file reference from any other .yml file that is being parsed by the expand templates task. The task will recursively read and import the settings – so be careful not to create a circular reference loop!

SFTP and SSH: Connect Via Keys

The SFTP and SSH tasks can now connect to remote servers via rsa keys, instead of just username/password. Specify the .key<code> attribute, instead of a password, to connect via rsa keys.

ssh do |ssh|
	ssh.server = "my server"
	ssh.key = ... an rsa key
	ssh.commands << "dir"
end

desc "Run ZipDirectory example"
ziptask do |zip|
	zip.output_path = File.dirname(__FILE__)
	zip.directories_to_zip = ["lib", "spec"]
	zip.additional_files = "README.markdown"
	zip.file = 'albacore_example.zip'
end