A
Alexey Verkhovsky
Dear all,
CruiseControl.rb is a continuous integration tool. Its basic purpose
in life is to alert members of a software project when one of them
checks something into source control that breaks the build. CC.rb is
easy to install, pleasant to use and simple to hack. It's written in
Ruby.
Version 1.3.0 is yet another small release, encompassing about 6
months of not-so-very-active ongoing development (keywords: simple,
small, sweet).
First and foremost, it's worth noticing that the default location of
CC.rb configuration files and build data has changed to $HOME/.cruise
(%USERPROFILE%\.cruise on Windows).
As for the new features, release 1.3.0 has two:
Build serialization:
This is a way to ensure that CC.rb never runs more than one build at
any given time. This helps to prevent conflicts between simultaneously
running builds using the same resource (e.g., a database or a
third-party service). To enable this, add
"Configuration.serialize_builds = true;
Configuration.serialized_build_timeout = 3.hours" to site_config.rb.
Automatic purging of all builds:
CC.rb uses the local file system for data storage. If there are
several thousand build directories, this may noticeably slow down
CC.rb dashboard. Now you can automatically tell it to purge old build
directories. To enable this, add "BuildReaper.number_of_builds_to_keep
= 200" to site_config.rb.
In addition, there is an experimental plugin infrastructure (similar
to Rails plugins). If you are writing CC.rb extensions, you may want
to look at it. Start with "script/cruise_plugin list help".
CHANGELOG
- cruise data (build results, etc) is stored in $HOME/.cruise/ by default
- builds can now be serialized - with a config option set, CC.rb
will only run one build at a time
- option to auto delete more than N builds
- [experimental] plugins can be installed w/ script/cruise_plugin script
- [bugfix] build requested status now stays on dashboard until a build starts
- [patch] subversion external support - Nathan Wilmes
- [patch] relative url support - Neal Clark
LINKS
Documentation: http://cruisecontrolrb.thoughtworks.com
Downloads: http://rubyforge.org/frs/?group_id=2918
Bug tracker: http://jira.public.thoughtworks.org/browse/CCRB
Users mailing list: (e-mail address removed)
UPGRADE PROCEDURE
IMPORTANT: as you saw above, the default location of CC.rb
configuration and data changed from "wherever you extracted
CruiseControl.rb sources" to $HOME/.cruise (%USERPROFILE%\.cruise on
Windows). This can mess up your current setup, if it makes any
assumptions about the location of those files, or if it runs CC.rb
processes in an environment where $HOME is not a writable directory.
0. Consider not upgrading at all - in many cases, 1.3 adds no tangible
value over 1.2.1.
1. Stop CC.rb if it's running.
2. Rename the directory containing the earlier CC.rb version (from now
on referred as [cruise]) to something else (e.g., [cruise].old).
3. Make sure you don't have $HOME/.cruise directory yet. Remove it if you do.
4. Download CC.rb 1.3.0 from http://rubyforge.org/frs/?group_id=2918
5. Extract it to [cruise] directory. Make sure that you moved the
earlier version away from [cruise] directory (step 2 above).
6. Copy [cruise].old/projects/ to [cruise]. Also copy
[cruise].old/config/site_config.rb to [cruise]/config/site_config.rb.
7. If you run CC.rb in an environment where $HOME is not a writable
directory, specify some other directory in CRUISE_DATA_ROOT, either by
assigning it to CRUISE_DATA_ROOT constant in site_config.rb, or
setting an OS environment variable of the same name before starting
CC.rb.
8. Start CC.rb. The first time you start it, it should automatically
move [cruise]/projects/ to $HOME/.cruise/. It will also copy
site_config.rb to $HOME/.cruise/.
FUTURE
After this release we are:
* migrating our RubyForge Subversion repository to Git (still on
RubyForge), which will improve hackability by making it easier to
maintain local branches.
* migrating the bug tracker to LightHouse. This already happened, in fact.
* making the version control interface pluggable, and implementing
Mercurial and Git support out of the box - this functionality will be
released in the next version - some time during the summer
Happy cruising.
CruiseControl.rb is a continuous integration tool. Its basic purpose
in life is to alert members of a software project when one of them
checks something into source control that breaks the build. CC.rb is
easy to install, pleasant to use and simple to hack. It's written in
Ruby.
Version 1.3.0 is yet another small release, encompassing about 6
months of not-so-very-active ongoing development (keywords: simple,
small, sweet).
First and foremost, it's worth noticing that the default location of
CC.rb configuration files and build data has changed to $HOME/.cruise
(%USERPROFILE%\.cruise on Windows).
As for the new features, release 1.3.0 has two:
Build serialization:
This is a way to ensure that CC.rb never runs more than one build at
any given time. This helps to prevent conflicts between simultaneously
running builds using the same resource (e.g., a database or a
third-party service). To enable this, add
"Configuration.serialize_builds = true;
Configuration.serialized_build_timeout = 3.hours" to site_config.rb.
Automatic purging of all builds:
CC.rb uses the local file system for data storage. If there are
several thousand build directories, this may noticeably slow down
CC.rb dashboard. Now you can automatically tell it to purge old build
directories. To enable this, add "BuildReaper.number_of_builds_to_keep
= 200" to site_config.rb.
In addition, there is an experimental plugin infrastructure (similar
to Rails plugins). If you are writing CC.rb extensions, you may want
to look at it. Start with "script/cruise_plugin list help".
CHANGELOG
- cruise data (build results, etc) is stored in $HOME/.cruise/ by default
- builds can now be serialized - with a config option set, CC.rb
will only run one build at a time
- option to auto delete more than N builds
- [experimental] plugins can be installed w/ script/cruise_plugin script
- [bugfix] build requested status now stays on dashboard until a build starts
- [patch] subversion external support - Nathan Wilmes
- [patch] relative url support - Neal Clark
LINKS
Documentation: http://cruisecontrolrb.thoughtworks.com
Downloads: http://rubyforge.org/frs/?group_id=2918
Bug tracker: http://jira.public.thoughtworks.org/browse/CCRB
Users mailing list: (e-mail address removed)
UPGRADE PROCEDURE
IMPORTANT: as you saw above, the default location of CC.rb
configuration and data changed from "wherever you extracted
CruiseControl.rb sources" to $HOME/.cruise (%USERPROFILE%\.cruise on
Windows). This can mess up your current setup, if it makes any
assumptions about the location of those files, or if it runs CC.rb
processes in an environment where $HOME is not a writable directory.
0. Consider not upgrading at all - in many cases, 1.3 adds no tangible
value over 1.2.1.
1. Stop CC.rb if it's running.
2. Rename the directory containing the earlier CC.rb version (from now
on referred as [cruise]) to something else (e.g., [cruise].old).
3. Make sure you don't have $HOME/.cruise directory yet. Remove it if you do.
4. Download CC.rb 1.3.0 from http://rubyforge.org/frs/?group_id=2918
5. Extract it to [cruise] directory. Make sure that you moved the
earlier version away from [cruise] directory (step 2 above).
6. Copy [cruise].old/projects/ to [cruise]. Also copy
[cruise].old/config/site_config.rb to [cruise]/config/site_config.rb.
7. If you run CC.rb in an environment where $HOME is not a writable
directory, specify some other directory in CRUISE_DATA_ROOT, either by
assigning it to CRUISE_DATA_ROOT constant in site_config.rb, or
setting an OS environment variable of the same name before starting
CC.rb.
8. Start CC.rb. The first time you start it, it should automatically
move [cruise]/projects/ to $HOME/.cruise/. It will also copy
site_config.rb to $HOME/.cruise/.
FUTURE
After this release we are:
* migrating our RubyForge Subversion repository to Git (still on
RubyForge), which will improve hackability by making it easier to
maintain local branches.
* migrating the bug tracker to LightHouse. This already happened, in fact.
* making the version control interface pluggable, and implementing
Mercurial and Git support out of the box - this functionality will be
released in the next version - some time during the summer
Happy cruising.