-
Notifications
You must be signed in to change notification settings - Fork 64
Configuration
There are a handful of global configuration options you should be aware of.
# LoggingYou can configure a global logging level in the Albacore global configuration block. The only option is :verbose
, actually. Any other value sets it back to "normal". Generally, the reason to set :verbose
is to see the exact command that is being executed for one of the CLI tasks.
Albacore.configure do |config|
config.log_level = :verbose
end
Apparently, you can control the log level of each task, individually.
foo :foo do |cmd|
foo.command = "path/to/foo"
foo.log_level = :verbose
end
You can set default configurations for a task-type in the Albacore global configuration block (nunit
is a "type" and nunit :foo do; end
is a "declaration" or an "instance" of a task, if you will). Any specific configuration in a task declaration will override these defaults.
Albacore.configure do |config|
config.msbuild.command = File.join(ENV["PROGRAMFILES"], "Microsoft Build Tools/bin/msbuild.exe")
end
Now, any task declaration of that type will have the configuration set already, so
msbuild :foo do |cmd|
# ...
end
Does not need a command
property and, in fact, it will evaluate to the value from the global block
command #=> "C:/Program Files/Microsoft Build Tools/bin/msbuild.exe"
Most tasks can be configured via an external YAML file. The main scenario is when you want to check-in the Rakefile
, but use per-environment configurations. For example, you could use YAML configuration to control connection strings on database tasks (local machine vs. build server).
Albacore will automatically search for a configuration files named after the down-cased task name being executed. If it finds one, it will auto-configure the task, then apply any configuration from the task declaration.
For example, given the following task declaration
foo :foo do |cmd|
cmd.command = "path/to/foo"
cmd.connection = "override-connection"
end
And the following configuration file, foo.yml
---
connection: "my-connection"
The resulting configuration will be
command #=> "path/to/foo"
connection #=> "override-connection
You can call also call the configure
method to explicitly provide a configuration file.
foo :foo do |cmd|
cmd.command = "path/to/foo"
cmd.configure "path/to/yaml/"
end
Most of the time, Rake is executed from the directory containing the Rakefile
and that's the best/easiest option. It's great if it happens automatically. Then, you can configure your tasks with short, relative file paths, like tools/nunit/nunit-console.exe
, where that tools/
directory is checked into your repository root.
However, some CI servers, in particular, are a pain in the ass and run Rake from a different working directory. If you have a setup like this, you'll need to use some of the Ruby File
methods to manipulate all of your paths.
First, understand the special __FILE__
variable in Ruby:
-
__FILE__
: the "relative" path to the file from the current execution directory
Then, this code will get you the absolute directory containing your Rakefile
File.expand_path(File.dirname(__FILE__))
And, you can use this and File.join
throughout your task configurations to fix all of your paths.
here = File.expand_path(File.dirname(__FILE__))
foo :foo do |cmd|
cmd.command = File.join(here, "path/to/foo")
end
While these recommendations will also work in the "good" scenario, avoid them until you need them because of all the clutter they introduce.