Some updates, and a couple of test requests

I did some work today to try to fix Cruise daemonization. Everything
looks ok to me on my Mac and Ruby 1.9.2 but I'm having trouble
installing and running JRuby locally. If others could take a poke at
this I'd greatly appreciate it.

Also, as far as I know, we don't need or use anything in the daemon/
subdirectory now; we're relying on Rails' server daemonization, the
killtree script, and straight-up kill to do the work.

The init.rb#stop_server method is using kill -KILL rather than kill
-INT, which is what I'd prefer, because shutting down the process
using -INT while the server is daemonized in Prod mode seems to cause
an infinite loop that I haven't locked down yet. Doesn't seem to
happen in dev mode.

Builders are now creating and cleaning up their own pid files, rather
than Platform creating the pid files at builder start time (and
getting cleaned up, well, never). If someone could explain why Cruise
is creating and using both .pid files and individual builder.lock
files that would be extremely helpful to me as a maintainer, since I
wasn't around for the creation of that code.

After this, nothing much is keeping us from cutting an RC1.

Brian

Replacing or supplementing Configuration.disable_build_now

Hi all,

Recently the number of things that the dashboard UI can do with your
builds has expanded a bit; you used to just being able to trigger
builds, but now you can add and kill them as well. So far we've been
using Configuration.can_build_now as a catch-all for these features
(when we guard them at all), but its name doesn't bear much
resemblance to its current usage.

There are a few ways we could go about improving this:

 1) deprecating Configuration.disable_build_now in favor of
Configuration.disable_admin_ui (or something similar)
 2) supplementing Configuration.disable_build_now by adding other
switches, like Configuration.disable_kill_builders and
Configuration.disable_add_project
 3) something else
 4) nothing else

My preference is for #1, because it's simple and captures the intent
of the switch better. #2 is more fine-grained, which might be helpful
in some cases. My suspicion is that you probably don't need that
granularity and anyone looking to disable Build Now probably wants to
disable those other things as well. I'm open to other suggestions but
I'd prefer to not ignore it.

Cheers,

Brian

Recent progress

Hi all,

Recently we've seen a number of big improvements:

 - new UI has been merged into master
 - a couple of fixes to Git support
 - you can now build and run a cruisecontrolrb gem
 - various improvements to documentation, help files, links, contributors list
 - improved management of environment variables in cruise_config
 - fixes to Bundler support
 - added a Kill Builder button (thanks to the folks at Square for this)
 - removed old and unused files from Rails 2 days
 - tests now pass in Windows (although builds still fail)

We're getting closer to our target date for a 2.0 release, which is
targeted for the 1st of July. Once gem package support is complete, in
the next couple of days, we'll tag and package a release as 2.0.0pre1
and push it out for general usage.

Brian

Next steps...

Hi,

Some of you may be wondering who I am. I'm Ketan from ThoughtWorks and 
one of the newest committers to ccrb. I've recently been doing some work 
to run ccrb as a jar (java -jar ccrb.jar) as a simple way to distribute 
ccrb. This is still work in progress. Later worked on fixing the build 
to make it go green 
<http://cruisecontrolrb.thoughtworks.com/builds/CruiseControl/bcc1d7267c145420606bce26006579ba3b17b0a7>.

So far here's what's been done so far(sorry, if this sounds like a 
repeat from previous conversations):

* A brand new ccrb machine - we scrapped the existing machine that was 
running an ancient OS and software which we could not figure out how it 
was setup(thanks @AjeyGore and Ranjib Dey from ThoughtWorks 
Infrastructure Support team)
* This has the latest version of ccrb deployed on it(rev bcc1d7).
* Get builder to work for ccrb. There was some work needed to make 
builder to work with rvm.
* Fix documentation generation - this was broken because of an api 
change between rails 2.x and 3.0.

Next steps:
===========

I feel the next steps should be to ensure that we are able to cut out a 
release(the last one was in mid 2009 - 2 years ago). To that effect I'd 
like to propose the following, and gather some consensus around the next 
steps.

Improving cross-platform support for process creation & destruction (was: Why there was no bundle in CC.rb originally)

On Fri, May 20, 2011 at 8:54 AM, Sidu Ponnappa <ckponnappa@...> wrote:
> Would it be fair to support Windows only via JRuby? That would make
> life much easier for you.
>
> Best,
> Sidu.
> http://c42.in

Sorry for the delay, folks - was away from the Internet for the last few days.

I've been spiking out ChildProcess
(https://github.com/jarib/childprocess; summary: extracted from
Selenium gem, a cross-platform library to launch and kill processes)
as a platform-relatively-agnostic replacement for CCRB's own
hand-rolled process-management code, and according to that's project's
implementation JRuby on Windows is the only platform that won't yield
a PID after process creation, which might actually create more
problems than it solves if we want to be able to kill live builders.

Questions to authors: Is there a particular reason why the master
Platform.create_child_process method is responsible for creating the
pid file, rather than the child builder creating it on launch? Also,
there's a reference in the comments that appears to suggest that the
builder process tries to hold a lock on its pid file, but that's not
the case in the code - it's using a separate file called builder.lock,
and the existence of the lock is used by the UI to determine
externally whether or not a given builder is running (rather than,
say, the builder's own reported status). Why is that the case? Was it
a concession to platforms that don't provide pids?

Why there was no bundle in CC.rb originally (and probably still shouldn't be now)

Problems setting Cruisecontrolrb

What does this point in Cruisecontrolrb prerequisites means?
The Ruby executable and the associated executable for which SCM you are
using must both be in your PATH.
And how to provide it?
Thanks!
--

-- 
View this message in context: http://old.nabble.com/Problems-setting-Cruisecontrolrb-tp31644346p31644346.html
Sent from the CruiseControl.rb - Development mailing list archive at Nabble.com.

Should Git be the default SCM?

Derek Hammer has very kindly offered this patch:
https://github.com/thoughtworks/cruisecontrol.rb/pull/21

This seems like a long-overdue change. Any objections if I merge it?

Cheers,

Brian

Recently in CC.rb activity

Recent commits/fixes in CC.rb:

 - Removed TimeFormatter, as it's now obsolete
   (Brian, 193c75f966327186d30613cdf484803cd8e025ce)
 - Removed all usages of deprecated assert_tag
   (Brian, 1ee3e073596ea8de4ca775577d9bb63a72d2afb0)
 - Fix for LH ticket #275 -Add the ability for git's log parser to
handle encoding as part of the commit object
   (Derek Hammer, 611812318bce0b53fa417b3788ef0c807d3eb254)
 - Fix for LH ticket #34 - Incorrect timezone in XmlStatusReport.aspx
(used by cctray)
   (Sudhindra Rao, e409c94169f528b79189852b029cfd89f8d07ed0)
 - Migrated controller tests over to use test "GET /foo should blah"
instead of def test_get_show - more to come in this vein as I attempt
to make CC.rb tests easier to read and interpret
   (Brian, cbed42a90762c23f5e34c561dbbfed759e3b0ed2)
 - Fix for GH issue #18 - ./cruise add command broken by Rails 3 upgrade
   (Brian, 5308ece2963246d6bf1ef329c24fddf21733a3da)
 - Replaced Prototype with jQuery, removed all Rails JS helpers,
removed JS routes that needed to be evaled
   (Brian, various commits)
 - Fix for "Never built" message broken in Rails 3 upgrade
   (Arun Agrawal, 7f7f593908de01643a124a1ca4cf7acd0d76f142)
 - Improved the way buttons are rendered
   (Brian, 7efddf376e7986b8f5cd05ed2a9ba4a860752bfb)

Additional contributors as Brian-pairs: Dean Cornish, Liauw Fendy,
Peter Murray, Adam Scott.

Thanks to all contributors and bug reporters for their help.

I'm thinking of moving all remaining LH tickets over to Github. Any objections?

Cheers,

Brian

Support for Bundler added

Hi all,

I've added basic support for Bundler in commit
2fe5d1b45105fd6f32a091165cdcb608403ac35b. Although I've tried to
adhere to the spirit of cross-platform compatibility, I haven't yet
had a chance to test it in Windows, so if you do so please share your
experience. Here's how it works:

 - If a project is configured with rake_command (or build_command is
omitted) and includes a Gemfile in its root, it's assumed that you
want to perform a bundle install.
 - You can explicitly disable this behavior with project.use_bundler = false.
 - If bundler support is triggered, CC.rb will perform a bundle check
followed by a bundle install if the check fails.
 - Going per Ryan McGeary's advice[1], bundle install defaults to
--path=vendor so as to avoid interfering with other gems installed on
the system. Open to feedback on this.
 - The absolute paths to each project's local vendor and Gemfiles are
passed as arguments to bundle install.

Relevant method is Build#bundle_install. Please take a look.

Cheers,

Brian

[1] "Vendor everything" still applies,
http://ryan.mcgeary.org/2011/02/09/vendor-everything-still-applies/

buildscontroller

Brian,
Also there is

     render :text => 'Project not specified', :status => 404 and return 
unless params[:project]

like duplication all over buildscontroller. Is that deemed to be low 
hanging fruit. I think the code is confusing because of such 
proliferation. What say?

(I am not being to be a code critique but trying to figure out what is 
our focus area.)

-Sudhindra

On 5/7/11 6:44 PM, Brian Guthrie wrote:
> Thanks Sudhindra. Much appreciated. :)
>
> On Sun, May 8, 2011 at 9:03 AM, Sudhindra
Rao<sudhindra.r.rao@...>  wrote:
>> Hi Brian,
>>
>> I think this is the highest priority and something that is a big hurdle in
>> using cruisecontrol.rb.
>>
>> "Add support for performing push-button deploys" - we've faked this
>> on projects in the past.
>>
>> and the second priority would be the dashboard - for me personally.
>>
>>
>> I would like to work on the push-button deploys - once I understand all the
>> changes that you have made recently.
>>
>> -Sudhindra
>>
>> _______________________________________________
>> Cruisecontrolrb-developers mailing list
>> Cruisecontrolrb-developers@...
>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>