gmane.comp.lang.ruby.cruise-control.devel

Some updates,and a couple of test requests

Brian Guthrie — 2011-07-03T06:37:22

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 supplementingConfiguration.disable_build_now

Brian Guthrie — 2011-06-22T05:01:05

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

Brian Guthrie — 2011-06-22T04:54:24

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...

Ketan Padegaonkar — 2011-06-08T17:36:26

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 < at >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.

This is fairly aggressive with the goal being able to cut a new release 
without having to stop the line for developing new features. Feel free 
to add anything that you feel should go into this list. These dates are 
just tentative in nature, we can be a lot aggressive if we feel we're up 
for it :)

* 1.5 beta end of next week(17th June)

Cut out a branch for 1.5 work. No new features land on this branch, 
anything new goes to the master branch to avoid regressions.

* 1.5RC week after(24th June)

Monitor any feedback around potential bugs that crop up and get them 
fixed. Cherry pick everything to master if needed.

* 1.5 week after(1st July)

Cut out a final release. Cherry pick everything to master if needed.

Just my 2 cents. Curious to hear from everyone else.

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

Brian Guthrie — 2011-05-22T09:56:59

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?

It feels to me like both the builder itself and the UI's use of it are
crying out for some sort of first-class domain model, but their
interactions with the builder are rather different - the UI launches,
reads the status of, and (someday) kills builders, builders themselves
read and write their own status and respond to kill and build
requests. Both require some subset of the same functionality. Right
now this stuff is floating around in some combination of Platform,
BuilderStatus, BuildBlocker, FileLock, and BuilderStarter, which has
been difficult for me to understand and maintain and exacerbates the
problem of poor builder status reporting in the UI.

Brian

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

Alexey Verkhovsky — 2011-05-18T15:46:31

Brian:

I see you added Gemfile to CC.rb. Not having external dependencies, binary
gems etc - this was, in fact, by design.

The rationale was that this tool should be easy to install for people who
know nothing about Ruby (because it was used on non-Ruby gigs; probably
still is). Therefore, it should only require Ruby and nothing else (not even
rubygems). Everything else is vendored.

I have a tentative (i.e., not extremely convinced) opinion that it better
remain this way.

--Alex

Problems setting Cruisecontrolrb

masterbloger — 2011-05-18T07:06:22

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!

Should Git be the default SCM?

Brian Guthrie — 2011-05-17T12:24:21

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

Brian Guthrie — 2011-05-17T11:55:51

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

Brian Guthrie — 2011-05-10T13:39:43

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/

cc.rb - high priority issues

Sudhindra Rao — 2011-05-07T23:03:54

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

CC.rb upgrades and maintenance

Brian Guthrie — 2011-05-04T08:16:49

Hi all,

I'd like to apologize. I haven't been able to offer the level of
support to the project that it deserves. With this in mind, I've
recently asked for, and been allowed, some time by ThoughtWorks to
update and improve CC.rb. Here's what's happened:

 - Framework has been upgraded to Rails 3
 - Along with that, there's been a lot of configuration, domain model,
and test cleanup
 - Minor aesthetic improvements (look for more here soon)
 - Can add new projects using the UI
 - Now manages dependencies with Bundler (naturally)
 - Lots of old Rails JS helpers replaced with properly-written JS
(framework is still Prototype)

Here's what I know works:

 - All tests pass
 - Cruise command appears to function correctly
 - Can build stuff (which is nice)
 - No major routes or configuration settings have been changed (to my knowledge)

Here's what I'd like to do:

 - Improve TW's ability to provide ongoing maintenance and support
 - Attempt to "do the right thing" wrt. Bundler; I'm open to feedback
on the appropriate level of support to offer, keeping in mind that
simplicity is key
 - Add support for performing push-button deploys - we've faked this
on projects in the past
 - Allow you to group builds, providing proper first-class domain
support for the difference between a project, a build, and a
particular execution of a build (for me personally, high pain, high
priority)
 - Some RJS still exists that I'd like to kill (moderate pain, low priority)
 - A lot could be done to improve the dashboard UX
 - I'd like to add support for JSON representations of most important
entities (perhaps JSONP too?)
 - I'd like to consolidate all bugs and feature requests in the Github
feature tracker and either close or fix what's already there
 - I'd like to find a way to distribute builds to multiple boxes
without spinning up multiple instances of CC.rb (high complexity, low
priority)
 - I haven't yet tested any of this in Windows (for me personally, low
pain, low priority)

Here's what I'd like to know:

 - Is anything in the above list worthwhile?
 - What are your most acute pain points?
 - What do you suggest for other reasonable next steps?

Thanks,

Brian

How about we turn off pull requests(Was: [GitHub] gnufied sent you a pull request fromgnufied/cruisecontrol.rb)

Chad Woolley — 2010-02-28T21:26:02

How about we turn off pull requests with message asking for
patch+ticket?  Since github doesn't allow non-account-owners to view
pull requests, that's the only way to allow all the collaborators to
help manage tickets/patches.

---------- Forwarded message ----------
From: GitHub <noreply-9UaJU3cA/F/QT0dZR+AlfA< at >public.gmane.org>
Date: Mon, Jan 25, 2010 at 12:52 PM
Subject: [GitHub] gnufied sent you a pull request from gnufied/cruisecontrol.rb
To: thewoolleyman-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org

gnufied wants you to pull from gnufied/cruisecontrol.rb at master

Body: Can you guys pull in from my fork? I have done two things:

1. Do not load smtl_tls.rb for Ruby 1.8.7.
2. Implement twitter support via plugin.

There are test cases to cover the functionality as well (and thus
shouldn't be a problem to merge).

View repository: http://github.com/gnufied/cruisecontrol.rb/tree/master

Disabling disabling of build button?

Chad Woolley — 2010-02-01T05:54:12

Hi,

I always have problems with the build not button being disabled when
it shouldn't be.  It's something with the ajax call it makes not
coming back, I suspect.  This seems even worse when caching is enabled
for the projects page.

I'd like to add a config flag to optionally disable the build button
auto-disable behavior.  This just means multiple build POST requests
could get submitted, but this isn't a problem, is it?  The server
should ignore them if a build is in progress (I assume this is already
the case, haven't looked closely).

Thoughts?

Thanks,

Caching?

Chad Woolley — 2010-01-01T10:39:52

Has anybody hacked caching into CCRB?  For a public server, the rss
and ccmenu resources should be cached, or else it kills the server
when a bunch of people hit the single mongrel.

Couple of bug fixes

Alexey Verkhovsky — 2009-12-10T18:11:22

Looking for some light cruise controlhelp

2009-11-24T01:14:12

Making output limit configurable

C. K. Ponnappa — 2009-10-29T20:11:04

Folks,

Shall I go ahead and merge Valentin's patch to make the output size 
configurable? You can find his changes at  
http://github.com/valo/cruisecontrol.rb

Thanks,
Sidu.

-------- Original Message --------
Subject: Re: [GitHub] valo sent you a message
Date: Fri, 30 Oct 2009 01:37:50 +0530
From: C. K. Ponnappa <ckponnappa-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>
To: Valentin Mihov <valentin.mihov-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>
References: <4ae8b72d2e1e7_17ed3fe199347af04fc-TqxH4ZT+qFGEmiPtDGWxttQT9D6RvEGW< at >public.gmane.org> 
<4AE90456.3040005-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> 
<45448450910290252h17a1c018ife55a1ffa194ca1b-JsoAwUIsXosN+BqQ9rBEUg< at >public.gmane.org>



Sure Valentin, more tests are always welcome. In the meanwhile I will 
get Alexey and others to review and once approved, I will merge changes.

Thanks ever so much!
Sidu.
http://blog.sidu.in
http://twitter.com/ponnappa

Valentin Mihov wrote:

(no subject)

Alexey Verkhovsky — 2009-10-05T16:59:47

A bug introduced by Rails upgrade

Alexey Verkhovsky — 2009-09-30T00:27:14

ccrb and mod_passenger(aka mod_rails)

Craig Forbes — 2009-09-23T14:53:23

Before I look into it I figured I should ask first to potentially save some 
wasted efford.  Has anyone attempted and/or succeeded in installing ccrb 
under mod_passenger on apache?

Thanks,
  -Craig