Cruisecontrolrb users - Apr 2008 - CruiseControl.rb 1.3.0

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: cruisecontrolrb-users at rubyforge.org


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.

-- 
Alexey Verkhovsky
CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
RubyWorks [http://rubyworks.thoughtworks.com]

Nice!  I''m especially in need of the build serialization. The other
stuff is
terriffic too.  Thanks for the great tool!

One request for .3.1 ...
Maybe (probably ;-) ) I''ve just had the bad luck not to find the
appropriate
section of the documentation but, with my config, if the preconditions fail
(recent e.g., there''re multiple migrations with the same number) the
build
email still says it passed because there were no errors in the test log
(because the tests never ran, so of course there are no errors).  If
it''s
there and I''m just missing it, I''d appreciate guidance.  If
not, it would be
great to have a variable to test (of whatever ''physical'' form
that needs to
take) from that reporting method to set the message more appropriately.  TIA
for considering it.

Best regards,
Bill

-----cruisecontrolrb-users-bounces at rubyforge.org wrote:
-----
> if the preconditions fail
> email still says it passed because there were no errors in the test log.
CC.rb has no concept of preconditions, and doesn''t care about the
contents
of test log to determine if the build passed or failed. Just the exit code
of the build command. If Rake exits with a zero exit code on failure, build
passed. So, if migration fails and CC.rb reports test passed, that should
be a bug in the build process.

Can you please give me more details?

1. Are you running your own Rake tasks, or CC.rb defaults?
2. What does ruby -v say?

--
Alex

>to add a PASSED/FAILED message to the
>email subject line.  It reports correctly if a test fails.
OK, so the build process does exit with non-zero code, and CC.rb does know
that the build has failed.
It also should put "passed" or "failed" into the subject of
the email. This
happens at lib/builder_plugins/email_notifier.rb, lines 40 and 46.
>How can I capture the errors that occur in
>task :cruise =>[''db:migrate'',
''db:test:purge'',
>''db:test:clone_structure'']
>so as to put the correct message on the email subject line?
Assuming that they do write something out into the stdout/stderr, you
should still see these failures in the build log section of the dashboard
page for that build. To add them to the email, you''d probably have to
rescue the errors (in the Rake build) and write them out to stderr in such
a way that can then be parsed. Then parse them out of build.output (which
is just the stderr+stdout of the build process). The build object is
available to all event handlers in the EmailNotifier (that would be
build_fixed() and build_finished() methods).

--
Alex

On Fri, 25 Apr 2008 01:28:06 +0200, Alexey Verkhovsky  
<alexey.verkhovsky@gmail.com> wrote:
> 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".
    Is there any documentation about this? The only examples are notifiers,  
is it just a plugin infrastructure for notifiers and other tasks when  
builds are finished, or could I implement other features with it?

    In particular, I'd be interested in turning my patch at  
http://jira.public.thoughtworks.org/browse/CCRB-172 to a plugin, so it's  
easier to maintain. Would that be possible at all?

-- 
Esteban Manchado Velázquez <estebanm@opera.com>, who kind of likes  
internal builds (except M2, who ate his mail)
_______________________________________________
Cruisecontrolrb-developers mailing list
Cruisecontrolrb-developers@rubyforge.org
http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers