Albacore v0.2.0 Preview 1 Is Available
A few days ago I pushed a preview version of Albacore up to RubyGems. The intention of doing a preview release was to show everyone the new direction that Albacore is heading and to get feedback from the community on that direction. Things are far from complete in this preview… there is a lot of work that I still want to pack in before the final release of v0.2.0… but there’s already enough change that has occurred, that I think it is time to start getting feedback and making improvements based on that.
Installing The Preview
This is all you need to install the preview version:
1: gem install albacore --pre
</div> </div>
The inclusion of ‘–pre’ on the command line will tell the gem system that you want to install the latest preview version of albacore. You will then need to modify your rake file to use the preview version (v0.2.0.preview1):
1: require 'rubygems'
2: gem 'albacore', '=v0.2.0.preview1'
3: require 'albacore'
</div> </div>
The second line tells the gem system to use the specific version of Albacore that you want, when the Albacore gem is required.
With all that being said, here’s what you can expect from the preview…
Reduced Syntax For Several Attributes
Many of the tasks that Albacore includes are what we call ‘command line tasks’ – these are tasks that call out to a command line tool. In previous releases, all of these tasks had their command line executable (or script or whatever) set through an attribute called ‘.path_to_command’. This lengthy name is hard to type and hard to remember if you don’t use it on a regular basis. With that in mind, we reduced the attribute to ‘.command’. For example:
1: nunit :test do |nunit|
2: nunit.command = "tools/nunit/nunit-console.exe"
3: # other settings here
4: end
</div> </div>
A few other tasks have had similar overhauls to specific attributes. the Unzip task, for example, has attributes renamed to ‘.file’ and ‘.destination’ to represent the zip file you want to unzip and where you want the contents sent. These changes should simplify your tasks a little and make them easier to read.
A Few New Tasks
In addition to the CSC task that I’ve already mentioned on this blog, there is also a new SpecflowReport task that let’s you run reports from specflow.
1: specflowreport :specflow do |sfr|
2: sfr.command = "path/to/specflow.exe"
3: sfr.projects "path/to/something.csproj"
4: sfr.reports "nunitexecutionreport"
5: sfr.options "/out:specs.html"
6: end
</div> </div>
Default To .NET 4 For MSBuild And CSC
FINALLY!!!!
I do have to apologize to the community of Albacore users for taking so long to get this done. I should have done it in a previous release, but I kept tell myself “no no… I’ll get v0.2.0 out the door soon…” … sorry about that. At long last, though, you no longer have to do any hard coded paths to make it work with .NET 4.
Not using .NET 4? Don’t worry! v0.2.0 will make your life easier, still! You can easily change framework versions with one simple statement in your task definition:
1: msbuild :build do |msb|
2: msb.use :net35
3: # other configuration here
4: end
</div> </div>
The .use(version) method is now available on the MSBuild and CSC tasks and let’s you specify which version of .NET you want to use when calling out to the command line. Here’s the current list of supported versions:
- :net2 or :net20 for v2.0.50727
- :net35 for v3.5
- :net4 or :net40 for v4.0.30319
Need another version? Drop us a line or submit a patch and we’ll get it added. (I know that this isn’t anywhere near the complete list. This is what I have on my machine, right now.)
A New Configuration System
This is one of the things I’m most excited about and hopefully something that will make your life even easier, with Albacore. There is a new configuration system that let’s you configure defaults for any attribute of any task in one simple place. Always using .Net 3.5 with MSBuild and don’t want to specify it in every msbuild task? no problem… Always want to use the same .command or .options with nunit? No problem… want to set the .log_level for every task? no problem…
1: Albacore.configure do |config|
2: config.log_level = :verbose
3: config.msbuild.use :net35
4: config.nunit do |nunit|
5: nunit.command = "path/to/nunit-console.exe"
6: nunit.options "/noshadow"
7: end
8: # additional task configuration here
9: end
</div> </div>
This Albacore.configure method can be called at the top of your rakefile and it will set the specified attributes for the specified tasks, on every instance of that task, to this default. Of course, you can still override any individual setting within any individual task definition.
In addition to the .configure method, this release of Albacore also makes it easy to configure any specific task through code, using a hash.
1: msbuild_settings = {
2: :properties => {:configuration => :release},
3: :targets => [:clean, :build]
4: }
5:
6: msbuild do |msb|
7: msb.update_attributes msbuild_settings
8: end
</div> </div>
Now you can set virtually any attribute of any task through code, outside of the task definition. You only need to provide a hash to the .update_attributes method on the task object.
A Better Internal Structure
I don’t want to bore everyone with a lot of detail here, but it is worth mentioning. Many of the individual modules that have previously been used in Albcore task objects have been consolidated into a single ‘AlbacoreModel’ module. In addition, many other changes have gone into the other modules to help clean them up, significantly. This is important not just for the current developers of Albacore, but also for the future developers and contributors. It will make life easier and allow others to extend Albacore with less trouble.
A Few Tasks Have Been Killed
This is probably going to be the most controversial thing that I’ve done in Albacore…
After a lot of thought and consideration about the focus of Albacore should be, I came to the conclusion that I want to help build the best set of build related tools for the .NET workd, running in Ruby / Rake. What this means is that I don’t think Albacore should be in the business of deployment. There are some tremendous deploy related gems already available and I want to encourage the use of those instead of having half-baked, 2nd class deployment capabilities built into Albacore.
In addition to this, I also realized that there are a few tasks that just don’t add any value. They are either duplicating functionality from somewhere else, or muddying the functionality that was intended.
With all that being said, here are the tasks that have been killed, and why:
-
rename: provides no value. just use ‘FileUtils.mv’ in a regular task. you get more options and better support from the ruby community with the FileUtils module
</li>
-
ssh: deploy related, which is not albacore’s "core". albacore is a build related framework, not deployment. suggest users switch to capistrano and webistrano if the want ssh stuff.
</li>
-
sftp: same as ssh
</li>
-
expandtemplates: while this is (mostly) functional and does provide some value, it’s a hack that i put together because i wasn’t aware of the existing templating solutions out there. ERB is built into to ruby and there are so many more available if people want them. I would suggest a switch to ERB or one of the other template systems if you need a templating solution.
</li>
-
plink: I was on the fence about deleting this one, since it is a command line tool for a specific tool (PuTTY). However, I decided to kill it because it is ultimate a deploy related tool – an SSH client.
</li> </ul>
Now, just because these have been officially removed from Albacore, doesn’t mean you are out of luck if you are using them… at least, not long-term. Check out the “what to expect in the future” to see how you’ll be able to revive these tasks (if you so desire) in the near future.
And Much Much More
There’s a lot more that has happened than this list can show – many miniscule details to give Albacore a much more solid feel to it. For a complete list of what has changed, check out the “v0.2.0” label on the Github Issues page – specifically look at the “Closed” tags to see what has been done (though the list of closed issues will continue to grow, while the preview 1 release will not change. I may release another preview as progress is made).
What To Expect In The Future
One of the things I want to do for the final release (probably really soon, cause I need this…) is create a very simple plug-in architecture to allow end-users of Albacore to add functionality. I want to create a system that is easy to extend and easy to change. I want to allow the system to grow and change with your needs, not just the needs of those who are speaking up on the mailing list or StackOverflow or whatever. If you want to re-add the ExpandTemplates task, if you want to re-add the SSH or SFTP task, or if you want to re-create them or create something new in a meaningful manner that suits your environment’s needs better, I want to make it easy for you.
The work that has gone into, and is still going on in, the refactoring of the internal structure in Albacore is going to facilitate a lot of this. In addition to that, there will be a simple drag-n-drop folder that you can add to any project anywhere on your system, and Albacore will pick up and automatically call ‘require’ on all ruby files in that folder. This code isn’t available, yet… you’ll have to wait for another preview (or maybe the final release if that happens sooner than expected) but it will be there. I need this functionality for myself and I’m sure others will take advantage of it, too.
In addition to the plug-in system, there will be other changes and details on a smaller scale: some additional work will be done on the CSC task; a few more bugs will be fixed; a few other tasks will have more options; and we’ll continue restructuring and fixing up the internal structure of Albacore, too.
As always, if you’re interested in contributing to Albacore in any way, head on over to http://albacorebuild.net and you can find links to the discussion group, source code, wiki, and much more.