From bguthrie at thoughtworks.com  Wed May  4 04:16:49 2011
From: bguthrie at thoughtworks.com (Brian Guthrie)
Date: Wed, 4 May 2011 18:16:49 +1000
Subject: [Cruisecontrolrb-developers] CC.rb upgrades and maintenance
Message-ID: <BANLkTikOUnqFFDAu977XXppzV2U+=tDrcg@mail.gmail.com>

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

From thewoolleyman at gmail.com  Wed May  4 11:03:16 2011
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Wed, 4 May 2011 08:03:16 -0700
Subject: [Cruisecontrolrb-developers] CC.rb upgrades and maintenance
In-Reply-To: <BANLkTikOUnqFFDAu977XXppzV2U+=tDrcg@mail.gmail.com>
References: <BANLkTikOUnqFFDAu977XXppzV2U+=tDrcg@mail.gmail.com>
Message-ID: <BANLkTimD6Cf_G5_m4b3af9uzAaDDcXbxSg@mail.gmail.com>

On Wed, May 4, 2011 at 1:16 AM, Brian Guthrie <bguthrie at thoughtworks.com> wrote:
> ?- What are your most acute pain points?
> ?- What do you suggest for other reasonable next steps?

Thanks for doing this.


My personal pain points are:

1. Ability to kill build and entire child processes tree from UI, even
if this is unix-only (see my code in the daemon/cruise init script for
an example.
2. No build button on the project page
3. Build button/state out of sync due to underlying file out of sync
(e.g. says building but actually not)

-- Chad

From bguthrie at thoughtworks.com  Thu May  5 03:39:24 2011
From: bguthrie at thoughtworks.com (Brian Guthrie)
Date: Thu, 5 May 2011 17:39:24 +1000
Subject: [Cruisecontrolrb-developers] CC.rb upgrades and maintenance
In-Reply-To: <BANLkTimD6Cf_G5_m4b3af9uzAaDDcXbxSg@mail.gmail.com>
References: <BANLkTikOUnqFFDAu977XXppzV2U+=tDrcg@mail.gmail.com>
	<BANLkTimD6Cf_G5_m4b3af9uzAaDDcXbxSg@mail.gmail.com>
Message-ID: <BANLkTinxZR86N3ypknWou+32CBVznrwAWw@mail.gmail.com>

I fixed #2 today and the code is in master. For the time being
clicking that button just triggers a refresh of the build page;
nothing fancy.

I looked at #1 but didn't get a chance to dive into it. I need to
check that the daemon code still functions after the upgrade. If it
does, is it just a matter of appropriating that code? Should this be
manifested as a new button, or a new state of the existing button?

#3 is tricky. I'm open to suggestions. Maybe another process that's
responsible for looking out for filesystem/builder discrepancies.

Brian

On Thu, May 5, 2011 at 1:03 AM, Chad Woolley <thewoolleyman at gmail.com> wrote:
> On Wed, May 4, 2011 at 1:16 AM, Brian Guthrie <bguthrie at thoughtworks.com> wrote:
>> ?- What are your most acute pain points?
>> ?- What do you suggest for other reasonable next steps?
>
> Thanks for doing this.
>
>
> My personal pain points are:
>
> 1. Ability to kill build and entire child processes tree from UI, even
> if this is unix-only (see my code in the daemon/cruise init script for
> an example.
> 2. No build button on the project page
> 3. Build button/state out of sync due to underlying file out of sync
> (e.g. says building but actually not)
>
> -- Chad
> _______________________________________________
> Cruisecontrolrb-developers mailing list
> Cruisecontrolrb-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>

From thewoolleyman at gmail.com  Fri May  6 00:27:38 2011
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Thu, 5 May 2011 21:27:38 -0700
Subject: [Cruisecontrolrb-developers] CC.rb upgrades and maintenance
In-Reply-To: <BANLkTinxZR86N3ypknWou+32CBVznrwAWw@mail.gmail.com>
References: <BANLkTikOUnqFFDAu977XXppzV2U+=tDrcg@mail.gmail.com>
	<BANLkTimD6Cf_G5_m4b3af9uzAaDDcXbxSg@mail.gmail.com>
	<BANLkTinxZR86N3ypknWou+32CBVznrwAWw@mail.gmail.com>
Message-ID: <BANLkTimoOsU-wJsCUkw-_Wc6Nt78NtkSqw@mail.gmail.com>

On Thu, May 5, 2011 at 12:39 AM, Brian Guthrie
<bguthrie at thoughtworks.com> wrote:
> I looked at #1 but didn't get a chance to dive into it. I need to
> check that the daemon code still functions after the upgrade. If it
> does, is it just a matter of appropriating that code? Should this be
> manifested as a new button, or a new state of the existing button?

Yeah, basically just walk the process tree of the builder.  A "kill
build" button is what I was thinking.  Good for testing, restarting
builds, runaway builds, etc.

From bguthrie at thoughtworks.com  Fri May  6 01:50:19 2011
From: bguthrie at thoughtworks.com (Brian Guthrie)
Date: Fri, 6 May 2011 15:50:19 +1000
Subject: [Cruisecontrolrb-developers] CC.rb upgrades and maintenance
In-Reply-To: <BANLkTimoOsU-wJsCUkw-_Wc6Nt78NtkSqw@mail.gmail.com>
References: <BANLkTikOUnqFFDAu977XXppzV2U+=tDrcg@mail.gmail.com>
	<BANLkTimD6Cf_G5_m4b3af9uzAaDDcXbxSg@mail.gmail.com>
	<BANLkTinxZR86N3ypknWou+32CBVznrwAWw@mail.gmail.com>
	<BANLkTimoOsU-wJsCUkw-_Wc6Nt78NtkSqw@mail.gmail.com>
Message-ID: <BANLkTikGbHYdfwGYfDowgA8nav0PUnDZgw@mail.gmail.com>

Should it immediately restart the builder afterwards?

On Fri, May 6, 2011 at 2:27 PM, Chad Woolley <thewoolleyman at gmail.com> wrote:
> On Thu, May 5, 2011 at 12:39 AM, Brian Guthrie
> <bguthrie at thoughtworks.com> wrote:
>> I looked at #1 but didn't get a chance to dive into it. I need to
>> check that the daemon code still functions after the upgrade. If it
>> does, is it just a matter of appropriating that code? Should this be
>> manifested as a new button, or a new state of the existing button?
>
> Yeah, basically just walk the process tree of the builder. ?A "kill
> build" button is what I was thinking. ?Good for testing, restarting
> builds, runaway builds, etc.
> _______________________________________________
> Cruisecontrolrb-developers mailing list
> Cruisecontrolrb-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>

From thewoolleyman at gmail.com  Fri May  6 16:29:38 2011
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Fri, 6 May 2011 13:29:38 -0700
Subject: [Cruisecontrolrb-developers] CC.rb upgrades and maintenance
In-Reply-To: <BANLkTikGbHYdfwGYfDowgA8nav0PUnDZgw@mail.gmail.com>
References: <BANLkTikOUnqFFDAu977XXppzV2U+=tDrcg@mail.gmail.com>
	<BANLkTimD6Cf_G5_m4b3af9uzAaDDcXbxSg@mail.gmail.com>
	<BANLkTinxZR86N3ypknWou+32CBVznrwAWw@mail.gmail.com>
	<BANLkTimoOsU-wJsCUkw-_Wc6Nt78NtkSqw@mail.gmail.com>
	<BANLkTikGbHYdfwGYfDowgA8nav0PUnDZgw@mail.gmail.com>
Message-ID: <BANLkTinEBY=xCCS8o=Z-WFfNhb-e21oWmw@mail.gmail.com>

On Thu, May 5, 2011 at 10:50 PM, Brian Guthrie
<bguthrie at thoughtworks.com> wrote:
> Should it immediately restart the builder afterwards?
>
Right, I guess it's really a "restart build(er)" button...

From sudhindra.r.rao at gmail.com  Sat May  7 19:03:54 2011
From: sudhindra.r.rao at gmail.com (Sudhindra Rao)
Date: Sat, 07 May 2011 16:03:54 -0700
Subject: [Cruisecontrolrb-developers] cc.rb - high priority issues
Message-ID: <4DC5CFDA.2090808@gmail.com>

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


From sudhindra.r.rao at gmail.com  Sun May  8 02:14:55 2011
From: sudhindra.r.rao at gmail.com (Sudhindra Rao)
Date: Sat, 07 May 2011 23:14:55 -0700
Subject: [Cruisecontrolrb-developers] cc.rb - high priority issues
In-Reply-To: <BANLkTikmBM3StFQwGbyL9ic7opec844Rtg@mail.gmail.com>
References: <4DC5CFDA.2090808@gmail.com>
	<BANLkTikmBM3StFQwGbyL9ic7opec844Rtg@mail.gmail.com>
Message-ID: <4DC634DF.3070303@gmail.com>

Hey Brian
So it says here

"class DocumentationController < ApplicationController
   caches_page :get

   # TODO Fix this. Fix it hard.
"

Do you know what needs to be fixed hard .. I see a number of ifs. Is 
that what is bothersome.
I am just trying to make some changes to slowly understand the codebase 
and thought would play with code lightly..

-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 at gmail.com>  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 at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>


From sudhindra.r.rao at gmail.com  Sun May  8 02:18:44 2011
From: sudhindra.r.rao at gmail.com (Sudhindra Rao)
Date: Sat, 07 May 2011 23:18:44 -0700
Subject: [Cruisecontrolrb-developers] buildscontroller
In-Reply-To: <BANLkTikmBM3StFQwGbyL9ic7opec844Rtg@mail.gmail.com>
References: <4DC5CFDA.2090808@gmail.com>
	<BANLkTikmBM3StFQwGbyL9ic7opec844Rtg@mail.gmail.com>
Message-ID: <4DC635C4.1010106@gmail.com>

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 at gmail.com>  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 at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>


From bguthrie at thoughtworks.com  Sun May  8 06:48:45 2011
From: bguthrie at thoughtworks.com (Brian Guthrie)
Date: Sun, 8 May 2011 20:48:45 +1000
Subject: [Cruisecontrolrb-developers] cc.rb - high priority issues
In-Reply-To: <4DC634DF.3070303@gmail.com>
References: <4DC5CFDA.2090808@gmail.com>
	<BANLkTikmBM3StFQwGbyL9ic7opec844Rtg@mail.gmail.com>
	<4DC634DF.3070303@gmail.com>
Message-ID: <BANLkTi=eDDJ4_caMqPicQwCkA5K+PydqJA@mail.gmail.com>

It's really not _that_ bad - I think the comment predates other
changes. These are basically the things that would be nice to clean
up:

 - Rendering documentation dynamically written as RedCloth templates
is an unusual pattern - perhaps unique. I'd like to bring this in line
with the mainstream, perhaps by compiling documentation to static
HTML. I'm not worried about the performance piece - caches_page should
take care of that. It's just an odd pattern.
 - There are things in those if-switches that seem better handled with routes.
 - I don't understand the middle if-switch - it seems to exist only to
dodge the :layout key used in the final switch.

Given those relatively minor quibbles, perhaps we should just remove
the comment and focus on other areas. But if you have any ideas for
improving the way documentation is handled please give it a go.

Cheers,

Brian

On Sun, May 8, 2011 at 4:14 PM, Sudhindra Rao <sudhindra.r.rao at gmail.com> wrote:
> Hey Brian
> So it says here
>
> "class DocumentationController < ApplicationController
> ?caches_page :get
>
> ?# TODO Fix this. Fix it hard.
> "
>
> Do you know what needs to be fixed hard .. I see a number of ifs. Is that
> what is bothersome.
> I am just trying to make some changes to slowly understand the codebase and
> thought would play with code lightly..
>
> -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 at gmail.com>
>> ?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 at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>>
>
> _______________________________________________
> Cruisecontrolrb-developers mailing list
> Cruisecontrolrb-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>

From bguthrie at thoughtworks.com  Sun May  8 06:50:14 2011
From: bguthrie at thoughtworks.com (Brian Guthrie)
Date: Sun, 8 May 2011 20:50:14 +1000
Subject: [Cruisecontrolrb-developers] buildscontroller
In-Reply-To: <4DC635C4.1010106@gmail.com>
References: <4DC5CFDA.2090808@gmail.com>
	<BANLkTikmBM3StFQwGbyL9ic7opec844Rtg@mail.gmail.com>
	<4DC635C4.1010106@gmail.com>
Message-ID: <BANLkTinfyz9b=24-irjVAnuZzO4iGTHWDw@mail.gmail.com>

I think those "project not specified" checks can be eliminated -
shouldn't routes take care of that?

On Sun, May 8, 2011 at 4:18 PM, Sudhindra Rao <sudhindra.r.rao at gmail.com> wrote:
> 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 at gmail.com>
>> ?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 at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>>
>
> _______________________________________________
> Cruisecontrolrb-developers mailing list
> Cruisecontrolrb-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>

From sudhindra.r.rao at gmail.com  Sun May  8 14:33:30 2011
From: sudhindra.r.rao at gmail.com (Sudhindra Rao)
Date: Sun, 08 May 2011 11:33:30 -0700
Subject: [Cruisecontrolrb-developers] cc.rb - high priority issues
In-Reply-To: <BANLkTi=eDDJ4_caMqPicQwCkA5K+PydqJA@mail.gmail.com>
References: <4DC5CFDA.2090808@gmail.com>
	<BANLkTikmBM3StFQwGbyL9ic7opec844Rtg@mail.gmail.com>
	<4DC634DF.3070303@gmail.com>
	<BANLkTi=eDDJ4_caMqPicQwCkA5K+PydqJA@mail.gmail.com>
Message-ID: <4DC6E1FA.90002@gmail.com>

Cool thanks Brian. Now I have an idea on what lines you are thinking. 
Agreed about the routes and documentation. To start I will atleast 
change the TODO to be more meaningful and reflect this discussion.

-Sudhindra

On 5/8/11 3:48 AM, Brian Guthrie wrote:
> It's really not _that_ bad - I think the comment predates other
> changes. These are basically the things that would be nice to clean
> up:
>
>   - Rendering documentation dynamically written as RedCloth templates
> is an unusual pattern - perhaps unique. I'd like to bring this in line
> with the mainstream, perhaps by compiling documentation to static
> HTML. I'm not worried about the performance piece - caches_page should
> take care of that. It's just an odd pattern.
>   - There are things in those if-switches that seem better handled with routes.
>   - I don't understand the middle if-switch - it seems to exist only to
> dodge the :layout key used in the final switch.
>
> Given those relatively minor quibbles, perhaps we should just remove
> the comment and focus on other areas. But if you have any ideas for
> improving the way documentation is handled please give it a go.
>
> Cheers,
>
> Brian
>
> On Sun, May 8, 2011 at 4:14 PM, Sudhindra Rao<sudhindra.r.rao at gmail.com>  wrote:
>> Hey Brian
>> So it says here
>>
>> "class DocumentationController<  ApplicationController
>>   caches_page :get
>>
>>   # TODO Fix this. Fix it hard.
>> "
>>
>> Do you know what needs to be fixed hard .. I see a number of ifs. Is that
>> what is bothersome.
>> I am just trying to make some changes to slowly understand the codebase and
>> thought would play with code lightly..
>>
>> -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 at gmail.com>
>>>   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 at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>>>
>> _______________________________________________
>> Cruisecontrolrb-developers mailing list
>> Cruisecontrolrb-developers at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>


From bguthrie at thoughtworks.com  Tue May 10 09:39:43 2011
From: bguthrie at thoughtworks.com (Brian Guthrie)
Date: Tue, 10 May 2011 23:39:43 +1000
Subject: [Cruisecontrolrb-developers] Support for Bundler added
Message-ID: <BANLkTikuN=Vitw-nehk3feZ2zqfRnQDGkQ@mail.gmail.com>

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/

From thewoolleyman at gmail.com  Tue May 10 19:15:31 2011
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Tue, 10 May 2011 16:15:31 -0700
Subject: [Cruisecontrolrb-developers] Support for Bundler added
In-Reply-To: <BANLkTikuN=Vitw-nehk3feZ2zqfRnQDGkQ@mail.gmail.com>
References: <BANLkTikuN=Vitw-nehk3feZ2zqfRnQDGkQ@mail.gmail.com>
Message-ID: <BANLkTikU0fK516JT4CaJzr4KiBQSa4j7Gg@mail.gmail.com>

On Tue, May 10, 2011 at 6:39 AM, Brian Guthrie
<bguthrie at thoughtworks.com> wrote:
> 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.

I'd allow the 'bundle install' command string to be
configurable/overrideable.  For example, I like to package all gems,
so I can run 'bundle install --local' and avoid the unnecessary time
to pull the index from the remote servers.  This should also allow
workarounds for any other edge cases involving special use of bundler.

-- Chad

From bguthrie at thoughtworks.com  Tue May 10 20:11:38 2011
From: bguthrie at thoughtworks.com (Brian Guthrie)
Date: Wed, 11 May 2011 10:11:38 +1000
Subject: [Cruisecontrolrb-developers] Support for Bundler added
In-Reply-To: <BANLkTikU0fK516JT4CaJzr4KiBQSa4j7Gg@mail.gmail.com>
References: <BANLkTikuN=Vitw-nehk3feZ2zqfRnQDGkQ@mail.gmail.com>
	<BANLkTikU0fK516JT4CaJzr4KiBQSa4j7Gg@mail.gmail.com>
Message-ID: <BANLkTikjAN-LCk6HPxfEeK5AXvzHWJSzBg@mail.gmail.com>

On Wed, May 11, 2011 at 9:15 AM, Chad Woolley <thewoolleyman at gmail.com> wrote:
> On Tue, May 10, 2011 at 6:39 AM, Brian Guthrie
> <bguthrie at thoughtworks.com> wrote:
>> 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.
>
> I'd allow the 'bundle install' command string to be
> configurable/overrideable. ?For example, I like to package all gems,
> so I can run 'bundle install --local' and avoid the unnecessary time
> to pull the index from the remote servers. ?This should also allow
> workarounds for any other edge cases involving special use of bundler.
>
> -- Chad

Thanks for the feedback. I agree that this behavior needs to be configurable.

My one question around overriding relates to actually locating the
bundle executable. Right now I'm attempting to resolve and use a full
path, because I'm worried that gem executables may not always be part
of the PATH; if that indeed is the case, allowing the user to override
that command would mean they'd either need to take responsibility for
specifying the path themselves, or CC.rb would need to perform some
kind of substitution to ensure that the full path gets added to the
executed command. Perhaps something like:

  project.bundle_install = "%bundle% install --local"

If specifying the full path is ridiculous, I'll remove it and move on.

Brian

From alexey.verkhovsky at gmail.com  Wed May 11 04:54:03 2011
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Wed, 11 May 2011 02:54:03 -0600
Subject: [Cruisecontrolrb-developers] Support for Bundler added
In-Reply-To: <BANLkTikjAN-LCk6HPxfEeK5AXvzHWJSzBg@mail.gmail.com>
References: <BANLkTikuN=Vitw-nehk3feZ2zqfRnQDGkQ@mail.gmail.com>
	<BANLkTikU0fK516JT4CaJzr4KiBQSa4j7Gg@mail.gmail.com>
	<BANLkTikjAN-LCk6HPxfEeK5AXvzHWJSzBg@mail.gmail.com>
Message-ID: <BANLkTinfJjvYNn+OWJP7deZkZmSzBFsy_Q@mail.gmail.com>

Similar story with path to rake executable is the reason why default build
behavior invokes rake as a Ruby script, not as an executable.

On Tue, May 10, 2011 at 6:11 PM, Brian Guthrie <bguthrie at thoughtworks.com>wrote:

> On Wed, May 11, 2011 at 9:15 AM, Chad Woolley <thewoolleyman at gmail.com>
> wrote:
> > On Tue, May 10, 2011 at 6:39 AM, Brian Guthrie
> > <bguthrie at thoughtworks.com> wrote:
> >> 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.
> >
> > I'd allow the 'bundle install' command string to be
> > configurable/overrideable.  For example, I like to package all gems,
> > so I can run 'bundle install --local' and avoid the unnecessary time
> > to pull the index from the remote servers.  This should also allow
> > workarounds for any other edge cases involving special use of bundler.
> >
> > -- Chad
>
> Thanks for the feedback. I agree that this behavior needs to be
> configurable.
>
> My one question around overriding relates to actually locating the
> bundle executable. Right now I'm attempting to resolve and use a full
> path, because I'm worried that gem executables may not always be part
> of the PATH; if that indeed is the case, allowing the user to override
> that command would mean they'd either need to take responsibility for
> specifying the path themselves, or CC.rb would need to perform some
> kind of substitution to ensure that the full path gets added to the
> executed command. Perhaps something like:
>
>  project.bundle_install = "%bundle% install --local"
>
> If specifying the full path is ridiculous, I'll remove it and move on.
>
> Brian
> _______________________________________________
> Cruisecontrolrb-developers mailing list
> Cruisecontrolrb-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>



-- 
Alexey Verkhovsky
http://alex-verkhovsky.blogspot.com/
CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/cruisecontrolrb-developers/attachments/20110511/5dd089b6/attachment.html>

From bguthrie at thoughtworks.com  Wed May 11 09:08:10 2011
From: bguthrie at thoughtworks.com (Brian Guthrie)
Date: Wed, 11 May 2011 23:08:10 +1000
Subject: [Cruisecontrolrb-developers] Support for Bundler added
In-Reply-To: <BANLkTinfJjvYNn+OWJP7deZkZmSzBFsy_Q@mail.gmail.com>
References: <BANLkTikuN=Vitw-nehk3feZ2zqfRnQDGkQ@mail.gmail.com>
	<BANLkTikU0fK516JT4CaJzr4KiBQSa4j7Gg@mail.gmail.com>
	<BANLkTikjAN-LCk6HPxfEeK5AXvzHWJSzBg@mail.gmail.com>
	<BANLkTinfJjvYNn+OWJP7deZkZmSzBFsy_Q@mail.gmail.com>
Message-ID: <BANLkTi=8VghyLCEyVokSwmB8Q9Za3hTODQ@mail.gmail.com>

Can you find the Rake executable by using RbConfig? Currently I'm
using the following to find the gem command:

  File.join RbConfig::CONFIG['bindir'], "gem"

and presumably you could do the same thing with Rake, but it needs to
be tested in JRuby.

Brian

On Wed, May 11, 2011 at 6:54 PM, Alexey Verkhovsky
<alexey.verkhovsky at gmail.com> wrote:
> Similar story with path to rake executable is the reason why default build
> behavior invokes rake as a Ruby script, not as an executable.
>
> On Tue, May 10, 2011 at 6:11 PM, Brian Guthrie <bguthrie at thoughtworks.com>
> wrote:
>>
>> On Wed, May 11, 2011 at 9:15 AM, Chad Woolley <thewoolleyman at gmail.com>
>> wrote:
>> > On Tue, May 10, 2011 at 6:39 AM, Brian Guthrie
>> > <bguthrie at thoughtworks.com> wrote:
>> >> 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.
>> >
>> > I'd allow the 'bundle install' command string to be
>> > configurable/overrideable. ?For example, I like to package all gems,
>> > so I can run 'bundle install --local' and avoid the unnecessary time
>> > to pull the index from the remote servers. ?This should also allow
>> > workarounds for any other edge cases involving special use of bundler.
>> >
>> > -- Chad
>>
>> Thanks for the feedback. I agree that this behavior needs to be
>> configurable.
>>
>> My one question around overriding relates to actually locating the
>> bundle executable. Right now I'm attempting to resolve and use a full
>> path, because I'm worried that gem executables may not always be part
>> of the PATH; if that indeed is the case, allowing the user to override
>> that command would mean they'd either need to take responsibility for
>> specifying the path themselves, or CC.rb would need to perform some
>> kind of substitution to ensure that the full path gets added to the
>> executed command. Perhaps something like:
>>
>> ?project.bundle_install = "%bundle% install --local"
>>
>> If specifying the full path is ridiculous, I'll remove it and move on.
>>
>> Brian
>> _______________________________________________
>> Cruisecontrolrb-developers mailing list
>> Cruisecontrolrb-developers at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>
>
>
> --
> Alexey Verkhovsky
> http://alex-verkhovsky.blogspot.com/
> CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
>
>
> _______________________________________________
> Cruisecontrolrb-developers mailing list
> Cruisecontrolrb-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>
>

From bguthrie at thoughtworks.com  Tue May 17 07:55:51 2011
From: bguthrie at thoughtworks.com (Brian Guthrie)
Date: Tue, 17 May 2011 21:55:51 +1000
Subject: [Cruisecontrolrb-developers] Recently in CC.rb activity
Message-ID: <BANLkTi=j=C-pZxwqEduCBqoDABbWEyt4uA@mail.gmail.com>

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

From bguthrie at thoughtworks.com  Tue May 17 08:24:21 2011
From: bguthrie at thoughtworks.com (Brian Guthrie)
Date: Tue, 17 May 2011 22:24:21 +1000
Subject: [Cruisecontrolrb-developers] Should Git be the default SCM?
Message-ID: <BANLkTikwwv9MSeqbb95BMVUVEgy_cjFX5Q@mail.gmail.com>

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

From alexey.verkhovsky at gmail.com  Tue May 17 08:44:05 2011
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Tue, 17 May 2011 06:44:05 -0600
Subject: [Cruisecontrolrb-developers] Should Git be the default SCM?
In-Reply-To: <BANLkTikwwv9MSeqbb95BMVUVEgy_cjFX5Q@mail.gmail.com>
References: <BANLkTikwwv9MSeqbb95BMVUVEgy_cjFX5Q@mail.gmail.com>
Message-ID: <BANLkTimiMT3VEbgKvdANaa9ks6Mv8g5ZXw@mail.gmail.com>

In principle, none. Documentation is worth looking at - there is probably a
mention of Subversion being the default there.

On Tue, May 17, 2011 at 6:24 AM, Brian Guthrie <bguthrie at thoughtworks.com>wrote:

> 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
> _______________________________________________
> Cruisecontrolrb-developers mailing list
> Cruisecontrolrb-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>



-- 
Alexey Verkhovsky
http://alex-verkhovsky.blogspot.com/
CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/cruisecontrolrb-developers/attachments/20110517/955b46b0/attachment.html>

From websnap at ukr.net  Wed May 18 03:06:22 2011
From: websnap at ukr.net (masterbloger)
Date: Wed, 18 May 2011 00:06:22 -0700 (PDT)
Subject: [Cruisecontrolrb-developers]  Problems setting Cruisecontrolrb
Message-ID: <31644346.post@talk.nabble.com>


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.


From bguthrie at thoughtworks.com  Wed May 18 03:19:29 2011
From: bguthrie at thoughtworks.com (Brian Guthrie)
Date: Wed, 18 May 2011 17:19:29 +1000
Subject: [Cruisecontrolrb-developers] Problems setting Cruisecontrolrb
In-Reply-To: <31644346.post@talk.nabble.com>
References: <31644346.post@talk.nabble.com>
Message-ID: <BANLkTikPS9ujBi58bPjtAx1HBW_FNKzjrw@mail.gmail.com>

Hi Masterbloger,

Unix (and Windows) systems use a PATH environment variable to store
the list of directories that the OS should search for a command that
you'd like to execute. Basically, if you open up a terminal and try to
execute "ruby" or "git" but fail to do so, you need to make sure that
the directories that contain those executables are part of your PATH.

More importantly, you need to make sure that whatever user (or
process) you're using to run CC.rb also has those directories in its
PATH environment variable.

If you can open up a terminal and execute these commands, you probably
don't need to worry about this. Are you having trouble running CC.rb?
If so, please direct your question to the cruisecontrolrb-users
mailing list, and we'll do our best to answer it there.

Cheers,

Brian

On Wed, May 18, 2011 at 5:06 PM, masterbloger <websnap at ukr.net> wrote:
>
> 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.
>
> _______________________________________________
> Cruisecontrolrb-developers mailing list
> Cruisecontrolrb-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>

From websnap at ukr.net  Wed May 18 03:46:55 2011
From: websnap at ukr.net (masterbloger)
Date: Wed, 18 May 2011 00:46:55 -0700 (PDT)
Subject: [Cruisecontrolrb-developers] Problems setting Cruisecontrolrb
In-Reply-To: <BANLkTikPS9ujBi58bPjtAx1HBW_FNKzjrw@mail.gmail.com>
References: <31644346.post@talk.nabble.com>
	<BANLkTikPS9ujBi58bPjtAx1HBW_FNKzjrw@mail.gmail.com>
Message-ID: <31644553.post@talk.nabble.com>


Ok. I describe problems with running CC.rb here:
http://old.nabble.com/Problems-setting-Cruisecontrolrb-to31644537.html



Brian Guthrie-3 wrote:
> 
> Hi Masterbloger,
> 
> Unix (and Windows) systems use a PATH environment variable to store
> the list of directories that the OS should search for a command that
> you'd like to execute. Basically, if you open up a terminal and try to
> execute "ruby" or "git" but fail to do so, you need to make sure that
> the directories that contain those executables are part of your PATH.
> 
> More importantly, you need to make sure that whatever user (or
> process) you're using to run CC.rb also has those directories in its
> PATH environment variable.
> 
> If you can open up a terminal and execute these commands, you probably
> don't need to worry about this. Are you having trouble running CC.rb?
> If so, please direct your question to the cruisecontrolrb-users
> mailing list, and we'll do our best to answer it there.
> 
> Cheers,
> 
> Brian
> 
> On Wed, May 18, 2011 at 5:06 PM, masterbloger <websnap at ukr.net> wrote:
>>
>> 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.
>>
>> _______________________________________________
>> Cruisecontrolrb-developers mailing list
>> Cruisecontrolrb-developers at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>
> _______________________________________________
> Cruisecontrolrb-developers mailing list
> Cruisecontrolrb-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
> 
> 

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


From alexey.verkhovsky at gmail.com  Wed May 18 11:46:31 2011
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Wed, 18 May 2011 09:46:31 -0600
Subject: [Cruisecontrolrb-developers] Why there was no bundle in CC.rb
 originally (and probably still shouldn't be now)
Message-ID: <BANLkTimFtzoAG8=Anm6-g47Y4fwbt9WnWg@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/cruisecontrolrb-developers/attachments/20110518/087693dc/attachment.html>

From alexey.verkhovsky at gmail.com  Wed May 18 11:51:31 2011
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Wed, 18 May 2011 09:51:31 -0600
Subject: [Cruisecontrolrb-developers] Why there was no bundle in CC.rb
 originally (and probably still shouldn't be now)
In-Reply-To: <BANLkTimFtzoAG8=Anm6-g47Y4fwbt9WnWg@mail.gmail.com>
References: <BANLkTimFtzoAG8=Anm6-g47Y4fwbt9WnWg@mail.gmail.com>
Message-ID: <BANLkTim-YO4O=GazjNs9ivQiWsL-xf=x4g@mail.gmail.com>

I do have a rather strong opinion that it should not use binary gems. This
adds a big barrier to entry, especially on Windoze.

On Wed, May 18, 2011 at 9:46 AM, Alexey Verkhovsky <
alexey.verkhovsky at gmail.com> wrote:

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


-- 
Alexey Verkhovsky
http://alex-verkhovsky.blogspot.com/
CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/cruisecontrolrb-developers/attachments/20110518/979c4f32/attachment.html>

From thewoolleyman at gmail.com  Wed May 18 16:17:58 2011
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Wed, 18 May 2011 13:17:58 -0700
Subject: [Cruisecontrolrb-developers] Why there was no bundle in CC.rb
 originally (and probably still shouldn't be now)
In-Reply-To: <BANLkTim-YO4O=GazjNs9ivQiWsL-xf=x4g@mail.gmail.com>
References: <BANLkTimFtzoAG8=Anm6-g47Y4fwbt9WnWg@mail.gmail.com>
	<BANLkTim-YO4O=GazjNs9ivQiWsL-xf=x4g@mail.gmail.com>
Message-ID: <BANLkTimF9Ebhd998hHfQrJwsJgw+Z8fQsw@mail.gmail.com>

If we use bundler with packaged gems (which we should, if we aren't),
that's essentially the same as vendoring them, which is what we did
before.

Agreed on avoiding use of binary gems.  Are we using any?  If so, we
should use a non-binary equivalent if at all possible.

On Wed, May 18, 2011 at 8:51 AM, Alexey Verkhovsky
<alexey.verkhovsky at gmail.com> wrote:
> I do have a rather strong opinion that it should not use binary gems. This
> adds a big barrier to entry, especially on Windoze.
>
> On Wed, May 18, 2011 at 9:46 AM, Alexey Verkhovsky
> <alexey.verkhovsky at gmail.com> wrote:
>>
>> 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
>>
>
>
>
> --
> Alexey Verkhovsky
> http://alex-verkhovsky.blogspot.com/
> CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
>
>
> _______________________________________________
> Cruisecontrolrb-developers mailing list
> Cruisecontrolrb-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>
>

From bguthrie at thoughtworks.com  Wed May 18 17:47:47 2011
From: bguthrie at thoughtworks.com (Brian Guthrie)
Date: Thu, 19 May 2011 07:47:47 +1000
Subject: [Cruisecontrolrb-developers] Why there was no bundle in CC.rb
 originally (and probably still shouldn't be now)
In-Reply-To: <BANLkTimF9Ebhd998hHfQrJwsJgw+Z8fQsw@mail.gmail.com>
References: <BANLkTimFtzoAG8=Anm6-g47Y4fwbt9WnWg@mail.gmail.com>
	<BANLkTim-YO4O=GazjNs9ivQiWsL-xf=x4g@mail.gmail.com>
	<BANLkTimF9Ebhd998hHfQrJwsJgw+Z8fQsw@mail.gmail.com>
Message-ID: <BANLkTikC2iDrdXcqy-Zwo9zEPy7MMO10zA@mail.gmail.com>

To the best of my knowledge, we do not have any dependencies on binary
gems at the moment. But even if we did, I don't see why it should be a
problem as long as Windows equivalents for those gems exist. I agree
that there's an expectation that CC.rb should be as widely compatible
as possible. I haven't had a chance to test every platform since the
upgrade, but I'm trying to remain true to the spirit of that goal.

But I don't see any good reason for the expectation that a Windows
user should be able to check out _the source code_ and immediately run
it. If they check out the source code, they can bundle install like
any other Ruby developer. If they install it as a gem, then let gem
dependencies be handled and installed as per normal. Either case would
handle binary gems just fine.

But if they just want a dependency-free _binary download_, there's no
reason why we can't package a zipfile that includes all dependencies
(using bundle install --deployment, for example) and make that
available. Such an artifact should be the output of a potential
Windows release build.

You may have noticed that I haven't checked in a Gemfile.lock either.
In case you were wondering why, it's because the last time I tried to
use Bundler on a cross-platform project (fairly recently--six months
ago or so) it failed to lock down dependencies in a platform-agnostic
way. This probably isn't an issue now, because there are no binary
gems, and so perhaps we should reconsider. But it would be if there
were.

Cheers,

Brian

On Thu, May 19, 2011 at 6:17 AM, Chad Woolley <thewoolleyman at gmail.com> wrote:
> If we use bundler with packaged gems (which we should, if we aren't),
> that's essentially the same as vendoring them, which is what we did
> before.
>
> Agreed on avoiding use of binary gems. ?Are we using any? ?If so, we
> should use a non-binary equivalent if at all possible.
>
> On Wed, May 18, 2011 at 8:51 AM, Alexey Verkhovsky
> <alexey.verkhovsky at gmail.com> wrote:
>> I do have a rather strong opinion that it should not use binary gems. This
>> adds a big barrier to entry, especially on Windoze.
>>
>> On Wed, May 18, 2011 at 9:46 AM, Alexey Verkhovsky
>> <alexey.verkhovsky at gmail.com> wrote:
>>>
>>> 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
>>>
>>
>>
>>
>> --
>> Alexey Verkhovsky
>> http://alex-verkhovsky.blogspot.com/
>> CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
>>
>>
>> _______________________________________________
>> Cruisecontrolrb-developers mailing list
>> Cruisecontrolrb-developers at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>
>>
> _______________________________________________
> Cruisecontrolrb-developers mailing list
> Cruisecontrolrb-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>

From thewoolleyman at gmail.com  Wed May 18 18:31:45 2011
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Wed, 18 May 2011 15:31:45 -0700
Subject: [Cruisecontrolrb-developers] Why there was no bundle in CC.rb
 originally (and probably still shouldn't be now)
In-Reply-To: <BANLkTikC2iDrdXcqy-Zwo9zEPy7MMO10zA@mail.gmail.com>
References: <BANLkTimFtzoAG8=Anm6-g47Y4fwbt9WnWg@mail.gmail.com>
	<BANLkTim-YO4O=GazjNs9ivQiWsL-xf=x4g@mail.gmail.com>
	<BANLkTimF9Ebhd998hHfQrJwsJgw+Z8fQsw@mail.gmail.com>
	<BANLkTikC2iDrdXcqy-Zwo9zEPy7MMO10zA@mail.gmail.com>
Message-ID: <BANLkTinAVhoL2TdudpXRuTPz8vCPLNWkag@mail.gmail.com>

Not checking in Gemfile.lock seems like a bad idea.  This allows
unspecified/indirect dependencies to float, which is almost guaranteed
to cause breakages as the world moves on.

On Wed, May 18, 2011 at 2:47 PM, Brian Guthrie
<bguthrie at thoughtworks.com> wrote:
> To the best of my knowledge, we do not have any dependencies on binary
> gems at the moment. But even if we did, I don't see why it should be a
> problem as long as Windows equivalents for those gems exist. I agree
> that there's an expectation that CC.rb should be as widely compatible
> as possible. I haven't had a chance to test every platform since the
> upgrade, but I'm trying to remain true to the spirit of that goal.
>
> But I don't see any good reason for the expectation that a Windows
> user should be able to check out _the source code_ and immediately run
> it. If they check out the source code, they can bundle install like
> any other Ruby developer. If they install it as a gem, then let gem
> dependencies be handled and installed as per normal. Either case would
> handle binary gems just fine.
>
> But if they just want a dependency-free _binary download_, there's no
> reason why we can't package a zipfile that includes all dependencies
> (using bundle install --deployment, for example) and make that
> available. Such an artifact should be the output of a potential
> Windows release build.
>
> You may have noticed that I haven't checked in a Gemfile.lock either.
> In case you were wondering why, it's because the last time I tried to
> use Bundler on a cross-platform project (fairly recently--six months
> ago or so) it failed to lock down dependencies in a platform-agnostic
> way. This probably isn't an issue now, because there are no binary
> gems, and so perhaps we should reconsider. But it would be if there
> were.
>
> Cheers,
>
> Brian
>
> On Thu, May 19, 2011 at 6:17 AM, Chad Woolley <thewoolleyman at gmail.com> wrote:
>> If we use bundler with packaged gems (which we should, if we aren't),
>> that's essentially the same as vendoring them, which is what we did
>> before.
>>
>> Agreed on avoiding use of binary gems. ?Are we using any? ?If so, we
>> should use a non-binary equivalent if at all possible.
>>
>> On Wed, May 18, 2011 at 8:51 AM, Alexey Verkhovsky
>> <alexey.verkhovsky at gmail.com> wrote:
>>> I do have a rather strong opinion that it should not use binary gems. This
>>> adds a big barrier to entry, especially on Windoze.
>>>
>>> On Wed, May 18, 2011 at 9:46 AM, Alexey Verkhovsky
>>> <alexey.verkhovsky at gmail.com> wrote:
>>>>
>>>> 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
>>>>
>>>
>>>
>>>
>>> --
>>> Alexey Verkhovsky
>>> http://alex-verkhovsky.blogspot.com/
>>> CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
>>>
>>>
>>> _______________________________________________
>>> Cruisecontrolrb-developers mailing list
>>> Cruisecontrolrb-developers at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>>
>>>
>> _______________________________________________
>> Cruisecontrolrb-developers mailing list
>> Cruisecontrolrb-developers at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>
> _______________________________________________
> Cruisecontrolrb-developers mailing list
> Cruisecontrolrb-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>

From bguthrie at thoughtworks.com  Wed May 18 19:33:32 2011
From: bguthrie at thoughtworks.com (Brian Guthrie)
Date: Thu, 19 May 2011 09:33:32 +1000
Subject: [Cruisecontrolrb-developers] Why there was no bundle in CC.rb
 originally (and probably still shouldn't be now)
In-Reply-To: <BANLkTinAVhoL2TdudpXRuTPz8vCPLNWkag@mail.gmail.com>
References: <BANLkTimFtzoAG8=Anm6-g47Y4fwbt9WnWg@mail.gmail.com>
	<BANLkTim-YO4O=GazjNs9ivQiWsL-xf=x4g@mail.gmail.com>
	<BANLkTimF9Ebhd998hHfQrJwsJgw+Z8fQsw@mail.gmail.com>
	<BANLkTikC2iDrdXcqy-Zwo9zEPy7MMO10zA@mail.gmail.com>
	<BANLkTinAVhoL2TdudpXRuTPz8vCPLNWkag@mail.gmail.com>
Message-ID: <BANLkTin0HUjbbn1HjrKUBqA1b5eex5GTwQ@mail.gmail.com>

If you specify a dependency on a binary gem, and attempt to lock your
project to that gem, Bundler will lock the version that's valid for
your current platform but not every conceivable platform. I consider
this a major flaw in their locking model, but I believe this may get
fixed in 1.1. I'll give it a shot in Windows today if I get the
chance. If everything looks okay, I'll try checking in the lockfile.

Brian

On Thu, May 19, 2011 at 8:31 AM, Chad Woolley <thewoolleyman at gmail.com> wrote:
> Not checking in Gemfile.lock seems like a bad idea. ?This allows
> unspecified/indirect dependencies to float, which is almost guaranteed
> to cause breakages as the world moves on.
>
> On Wed, May 18, 2011 at 2:47 PM, Brian Guthrie
> <bguthrie at thoughtworks.com> wrote:
>> To the best of my knowledge, we do not have any dependencies on binary
>> gems at the moment. But even if we did, I don't see why it should be a
>> problem as long as Windows equivalents for those gems exist. I agree
>> that there's an expectation that CC.rb should be as widely compatible
>> as possible. I haven't had a chance to test every platform since the
>> upgrade, but I'm trying to remain true to the spirit of that goal.
>>
>> But I don't see any good reason for the expectation that a Windows
>> user should be able to check out _the source code_ and immediately run
>> it. If they check out the source code, they can bundle install like
>> any other Ruby developer. If they install it as a gem, then let gem
>> dependencies be handled and installed as per normal. Either case would
>> handle binary gems just fine.
>>
>> But if they just want a dependency-free _binary download_, there's no
>> reason why we can't package a zipfile that includes all dependencies
>> (using bundle install --deployment, for example) and make that
>> available. Such an artifact should be the output of a potential
>> Windows release build.
>>
>> You may have noticed that I haven't checked in a Gemfile.lock either.
>> In case you were wondering why, it's because the last time I tried to
>> use Bundler on a cross-platform project (fairly recently--six months
>> ago or so) it failed to lock down dependencies in a platform-agnostic
>> way. This probably isn't an issue now, because there are no binary
>> gems, and so perhaps we should reconsider. But it would be if there
>> were.
>>
>> Cheers,
>>
>> Brian
>>
>> On Thu, May 19, 2011 at 6:17 AM, Chad Woolley <thewoolleyman at gmail.com> wrote:
>>> If we use bundler with packaged gems (which we should, if we aren't),
>>> that's essentially the same as vendoring them, which is what we did
>>> before.
>>>
>>> Agreed on avoiding use of binary gems. ?Are we using any? ?If so, we
>>> should use a non-binary equivalent if at all possible.
>>>
>>> On Wed, May 18, 2011 at 8:51 AM, Alexey Verkhovsky
>>> <alexey.verkhovsky at gmail.com> wrote:
>>>> I do have a rather strong opinion that it should not use binary gems. This
>>>> adds a big barrier to entry, especially on Windoze.
>>>>
>>>> On Wed, May 18, 2011 at 9:46 AM, Alexey Verkhovsky
>>>> <alexey.verkhovsky at gmail.com> wrote:
>>>>>
>>>>> 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
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Alexey Verkhovsky
>>>> http://alex-verkhovsky.blogspot.com/
>>>> CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
>>>>
>>>>
>>>> _______________________________________________
>>>> Cruisecontrolrb-developers mailing list
>>>> Cruisecontrolrb-developers at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>>>
>>>>
>>> _______________________________________________
>>> Cruisecontrolrb-developers mailing list
>>> Cruisecontrolrb-developers at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>>
>> _______________________________________________
>> Cruisecontrolrb-developers mailing list
>> Cruisecontrolrb-developers at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>
> _______________________________________________
> Cruisecontrolrb-developers mailing list
> Cruisecontrolrb-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>

From thewoolleyman at gmail.com  Wed May 18 20:02:13 2011
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Wed, 18 May 2011 17:02:13 -0700
Subject: [Cruisecontrolrb-developers] Why there was no bundle in CC.rb
 originally (and probably still shouldn't be now)
In-Reply-To: <BANLkTin0HUjbbn1HjrKUBqA1b5eex5GTwQ@mail.gmail.com>
References: <BANLkTimFtzoAG8=Anm6-g47Y4fwbt9WnWg@mail.gmail.com>
	<BANLkTim-YO4O=GazjNs9ivQiWsL-xf=x4g@mail.gmail.com>
	<BANLkTimF9Ebhd998hHfQrJwsJgw+Z8fQsw@mail.gmail.com>
	<BANLkTikC2iDrdXcqy-Zwo9zEPy7MMO10zA@mail.gmail.com>
	<BANLkTinAVhoL2TdudpXRuTPz8vCPLNWkag@mail.gmail.com>
	<BANLkTin0HUjbbn1HjrKUBqA1b5eex5GTwQ@mail.gmail.com>
Message-ID: <BANLkTikWk=KSWa0Cac9tMuXDXG9TjkbEYA@mail.gmail.com>

Hmm.  I think Alexey may be right.  Why don't we just continue
vendoring everything, so it is completely self-contained and works out
of the box?  That solves many problems, and I don't see that many
practical problems to NOT using Bundler.  It only really impacts
people hacking on CCRB and wishing to change dependencies, which
should be a very small subset of people who should be able to deal
with vendored gems vs. bundler.

On Wed, May 18, 2011 at 4:33 PM, Brian Guthrie
<bguthrie at thoughtworks.com> wrote:
> If you specify a dependency on a binary gem, and attempt to lock your
> project to that gem, Bundler will lock the version that's valid for
> your current platform but not every conceivable platform. I consider
> this a major flaw in their locking model, but I believe this may get
> fixed in 1.1. I'll give it a shot in Windows today if I get the
> chance. If everything looks okay, I'll try checking in the lockfile.
>
> Brian
>
> On Thu, May 19, 2011 at 8:31 AM, Chad Woolley <thewoolleyman at gmail.com> wrote:
>> Not checking in Gemfile.lock seems like a bad idea. ?This allows
>> unspecified/indirect dependencies to float, which is almost guaranteed
>> to cause breakages as the world moves on.
>>
>> On Wed, May 18, 2011 at 2:47 PM, Brian Guthrie
>> <bguthrie at thoughtworks.com> wrote:
>>> To the best of my knowledge, we do not have any dependencies on binary
>>> gems at the moment. But even if we did, I don't see why it should be a
>>> problem as long as Windows equivalents for those gems exist. I agree
>>> that there's an expectation that CC.rb should be as widely compatible
>>> as possible. I haven't had a chance to test every platform since the
>>> upgrade, but I'm trying to remain true to the spirit of that goal.
>>>
>>> But I don't see any good reason for the expectation that a Windows
>>> user should be able to check out _the source code_ and immediately run
>>> it. If they check out the source code, they can bundle install like
>>> any other Ruby developer. If they install it as a gem, then let gem
>>> dependencies be handled and installed as per normal. Either case would
>>> handle binary gems just fine.
>>>
>>> But if they just want a dependency-free _binary download_, there's no
>>> reason why we can't package a zipfile that includes all dependencies
>>> (using bundle install --deployment, for example) and make that
>>> available. Such an artifact should be the output of a potential
>>> Windows release build.
>>>
>>> You may have noticed that I haven't checked in a Gemfile.lock either.
>>> In case you were wondering why, it's because the last time I tried to
>>> use Bundler on a cross-platform project (fairly recently--six months
>>> ago or so) it failed to lock down dependencies in a platform-agnostic
>>> way. This probably isn't an issue now, because there are no binary
>>> gems, and so perhaps we should reconsider. But it would be if there
>>> were.
>>>
>>> Cheers,
>>>
>>> Brian
>>>
>>> On Thu, May 19, 2011 at 6:17 AM, Chad Woolley <thewoolleyman at gmail.com> wrote:
>>>> If we use bundler with packaged gems (which we should, if we aren't),
>>>> that's essentially the same as vendoring them, which is what we did
>>>> before.
>>>>
>>>> Agreed on avoiding use of binary gems. ?Are we using any? ?If so, we
>>>> should use a non-binary equivalent if at all possible.
>>>>
>>>> On Wed, May 18, 2011 at 8:51 AM, Alexey Verkhovsky
>>>> <alexey.verkhovsky at gmail.com> wrote:
>>>>> I do have a rather strong opinion that it should not use binary gems. This
>>>>> adds a big barrier to entry, especially on Windoze.
>>>>>
>>>>> On Wed, May 18, 2011 at 9:46 AM, Alexey Verkhovsky
>>>>> <alexey.verkhovsky at gmail.com> wrote:
>>>>>>
>>>>>> 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
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Alexey Verkhovsky
>>>>> http://alex-verkhovsky.blogspot.com/
>>>>> CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Cruisecontrolrb-developers mailing list
>>>>> Cruisecontrolrb-developers at rubyforge.org
>>>>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Cruisecontrolrb-developers mailing list
>>>> Cruisecontrolrb-developers at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>>>
>>> _______________________________________________
>>> Cruisecontrolrb-developers mailing list
>>> Cruisecontrolrb-developers at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>>
>> _______________________________________________
>> Cruisecontrolrb-developers mailing list
>> Cruisecontrolrb-developers at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>
> _______________________________________________
> Cruisecontrolrb-developers mailing list
> Cruisecontrolrb-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>

From bguthrie at thoughtworks.com  Wed May 18 20:54:28 2011
From: bguthrie at thoughtworks.com (Brian Guthrie)
Date: Thu, 19 May 2011 10:54:28 +1000
Subject: [Cruisecontrolrb-developers] Why there was no bundle in CC.rb
 originally (and probably still shouldn't be now)
In-Reply-To: <BANLkTikWk=KSWa0Cac9tMuXDXG9TjkbEYA@mail.gmail.com>
References: <BANLkTimFtzoAG8=Anm6-g47Y4fwbt9WnWg@mail.gmail.com>
	<BANLkTim-YO4O=GazjNs9ivQiWsL-xf=x4g@mail.gmail.com>
	<BANLkTimF9Ebhd998hHfQrJwsJgw+Z8fQsw@mail.gmail.com>
	<BANLkTikC2iDrdXcqy-Zwo9zEPy7MMO10zA@mail.gmail.com>
	<BANLkTinAVhoL2TdudpXRuTPz8vCPLNWkag@mail.gmail.com>
	<BANLkTin0HUjbbn1HjrKUBqA1b5eex5GTwQ@mail.gmail.com>
	<BANLkTikWk=KSWa0Cac9tMuXDXG9TjkbEYA@mail.gmail.com>
Message-ID: <BANLkTikNfXvOH=od=qtatn_+mzYxoEQ5Mw@mail.gmail.com>

Vendoring gems doesn't really solve the multi-platform binary problem,
which we'd have to hack in special code to fix, as I understand it
(require "#{RUBY_PLATFORM}/binary_gem"). I'm not worried about gem
dependencies floating a little bit; our Gemfile is fairly conservative
in its versioning, and we have reasonably comprehensive tests. And
anyway, none of this is a problem if we don't have binaries; you were
right about the lockfile, and I'll check it in if I can. (Another
thing I've seen tried is checking in Gemfile.windows, which gets
copied over to become the main lockfile on demand.)

Unless it really is a terrible idea, I'd prefer to continue to use
Bundler and vendor everything on demand for things that need it, like
self-contained releases. Otherwise the existing infrastructure is
pretty capable of resolving dependencies.

CC.rb is an open source project, and making it easy for people to
contribute is important. I'd also like us to follow community norms
where possible. Managing gems has dramatically improved since CC.rb
was written, and what made sense in 2007 may not make sense now.
Relying on Bundler to manage dependencies helps us achieve that goal,
makes some tasks easier, and costs us very little.

Brian

On Thu, May 19, 2011 at 10:02 AM, Chad Woolley <thewoolleyman at gmail.com> wrote:
> Hmm. ?I think Alexey may be right. ?Why don't we just continue
> vendoring everything, so it is completely self-contained and works out
> of the box? ?That solves many problems, and I don't see that many
> practical problems to NOT using Bundler. ?It only really impacts
> people hacking on CCRB and wishing to change dependencies, which
> should be a very small subset of people who should be able to deal
> with vendored gems vs. bundler.
>
> On Wed, May 18, 2011 at 4:33 PM, Brian Guthrie
> <bguthrie at thoughtworks.com> wrote:
>> If you specify a dependency on a binary gem, and attempt to lock your
>> project to that gem, Bundler will lock the version that's valid for
>> your current platform but not every conceivable platform. I consider
>> this a major flaw in their locking model, but I believe this may get
>> fixed in 1.1. I'll give it a shot in Windows today if I get the
>> chance. If everything looks okay, I'll try checking in the lockfile.
>>
>> Brian
>>
>> On Thu, May 19, 2011 at 8:31 AM, Chad Woolley <thewoolleyman at gmail.com> wrote:
>>> Not checking in Gemfile.lock seems like a bad idea. ?This allows
>>> unspecified/indirect dependencies to float, which is almost guaranteed
>>> to cause breakages as the world moves on.
>>>
>>> On Wed, May 18, 2011 at 2:47 PM, Brian Guthrie
>>> <bguthrie at thoughtworks.com> wrote:
>>>> To the best of my knowledge, we do not have any dependencies on binary
>>>> gems at the moment. But even if we did, I don't see why it should be a
>>>> problem as long as Windows equivalents for those gems exist. I agree
>>>> that there's an expectation that CC.rb should be as widely compatible
>>>> as possible. I haven't had a chance to test every platform since the
>>>> upgrade, but I'm trying to remain true to the spirit of that goal.
>>>>
>>>> But I don't see any good reason for the expectation that a Windows
>>>> user should be able to check out _the source code_ and immediately run
>>>> it. If they check out the source code, they can bundle install like
>>>> any other Ruby developer. If they install it as a gem, then let gem
>>>> dependencies be handled and installed as per normal. Either case would
>>>> handle binary gems just fine.
>>>>
>>>> But if they just want a dependency-free _binary download_, there's no
>>>> reason why we can't package a zipfile that includes all dependencies
>>>> (using bundle install --deployment, for example) and make that
>>>> available. Such an artifact should be the output of a potential
>>>> Windows release build.
>>>>
>>>> You may have noticed that I haven't checked in a Gemfile.lock either.
>>>> In case you were wondering why, it's because the last time I tried to
>>>> use Bundler on a cross-platform project (fairly recently--six months
>>>> ago or so) it failed to lock down dependencies in a platform-agnostic
>>>> way. This probably isn't an issue now, because there are no binary
>>>> gems, and so perhaps we should reconsider. But it would be if there
>>>> were.
>>>>
>>>> Cheers,
>>>>
>>>> Brian
>>>>
>>>> On Thu, May 19, 2011 at 6:17 AM, Chad Woolley <thewoolleyman at gmail.com> wrote:
>>>>> If we use bundler with packaged gems (which we should, if we aren't),
>>>>> that's essentially the same as vendoring them, which is what we did
>>>>> before.
>>>>>
>>>>> Agreed on avoiding use of binary gems. ?Are we using any? ?If so, we
>>>>> should use a non-binary equivalent if at all possible.
>>>>>
>>>>> On Wed, May 18, 2011 at 8:51 AM, Alexey Verkhovsky
>>>>> <alexey.verkhovsky at gmail.com> wrote:
>>>>>> I do have a rather strong opinion that it should not use binary gems. This
>>>>>> adds a big barrier to entry, especially on Windoze.
>>>>>>
>>>>>> On Wed, May 18, 2011 at 9:46 AM, Alexey Verkhovsky
>>>>>> <alexey.verkhovsky at gmail.com> wrote:
>>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Alexey Verkhovsky
>>>>>> http://alex-verkhovsky.blogspot.com/
>>>>>> CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Cruisecontrolrb-developers mailing list
>>>>>> Cruisecontrolrb-developers at rubyforge.org
>>>>>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> Cruisecontrolrb-developers mailing list
>>>>> Cruisecontrolrb-developers at rubyforge.org
>>>>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>>>>
>>>> _______________________________________________
>>>> Cruisecontrolrb-developers mailing list
>>>> Cruisecontrolrb-developers at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>>>
>>> _______________________________________________
>>> Cruisecontrolrb-developers mailing list
>>> Cruisecontrolrb-developers at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>>
>> _______________________________________________
>> Cruisecontrolrb-developers mailing list
>> Cruisecontrolrb-developers at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>
> _______________________________________________
> Cruisecontrolrb-developers mailing list
> Cruisecontrolrb-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>

From thewoolleyman at gmail.com  Wed May 18 22:24:04 2011
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Wed, 18 May 2011 19:24:04 -0700
Subject: [Cruisecontrolrb-developers] Why there was no bundle in CC.rb
 originally (and probably still shouldn't be now)
In-Reply-To: <BANLkTikNfXvOH=od=qtatn_+mzYxoEQ5Mw@mail.gmail.com>
References: <BANLkTimFtzoAG8=Anm6-g47Y4fwbt9WnWg@mail.gmail.com>
	<BANLkTim-YO4O=GazjNs9ivQiWsL-xf=x4g@mail.gmail.com>
	<BANLkTimF9Ebhd998hHfQrJwsJgw+Z8fQsw@mail.gmail.com>
	<BANLkTikC2iDrdXcqy-Zwo9zEPy7MMO10zA@mail.gmail.com>
	<BANLkTinAVhoL2TdudpXRuTPz8vCPLNWkag@mail.gmail.com>
	<BANLkTin0HUjbbn1HjrKUBqA1b5eex5GTwQ@mail.gmail.com>
	<BANLkTikWk=KSWa0Cac9tMuXDXG9TjkbEYA@mail.gmail.com>
	<BANLkTikNfXvOH=od=qtatn_+mzYxoEQ5Mw@mail.gmail.com>
Message-ID: <BANLkTik41PK4H7HuZ+Vno8_3QaRt4oYtqg@mail.gmail.com>

"I'd prefer to continue to use Bundler and vendor everything on demand
for things that need it, like self-contained releases." - not positive
what that means, but it sounds like it could be good :)

Also, the Gemfile.windows sounds like a good alternative, especially
if there is a self-contained release for windows users (and a separate
one for unix users if they must differ) so end users don't have to
think about gemfiles at all.

Not as easy as just checking out source, but I can see the benefit of
sticking with standards, and Bundler is definitely the standard now.

On Wed, May 18, 2011 at 5:54 PM, Brian Guthrie
<bguthrie at thoughtworks.com> wrote:
> Vendoring gems doesn't really solve the multi-platform binary problem,
> which we'd have to hack in special code to fix, as I understand it
> (require "#{RUBY_PLATFORM}/binary_gem"). I'm not worried about gem
> dependencies floating a little bit; our Gemfile is fairly conservative
> in its versioning, and we have reasonably comprehensive tests. And
> anyway, none of this is a problem if we don't have binaries; you were
> right about the lockfile, and I'll check it in if I can. (Another
> thing I've seen tried is checking in Gemfile.windows, which gets
> copied over to become the main lockfile on demand.)
>
> Unless it really is a terrible idea, I'd prefer to continue to use
> Bundler and vendor everything on demand for things that need it, like
> self-contained releases. Otherwise the existing infrastructure is
> pretty capable of resolving dependencies.
>
> CC.rb is an open source project, and making it easy for people to
> contribute is important. I'd also like us to follow community norms
> where possible. Managing gems has dramatically improved since CC.rb
> was written, and what made sense in 2007 may not make sense now.
> Relying on Bundler to manage dependencies helps us achieve that goal,
> makes some tasks easier, and costs us very little.
>
> Brian
>
> On Thu, May 19, 2011 at 10:02 AM, Chad Woolley <thewoolleyman at gmail.com> wrote:
>> Hmm. ?I think Alexey may be right. ?Why don't we just continue
>> vendoring everything, so it is completely self-contained and works out
>> of the box? ?That solves many problems, and I don't see that many
>> practical problems to NOT using Bundler. ?It only really impacts
>> people hacking on CCRB and wishing to change dependencies, which
>> should be a very small subset of people who should be able to deal
>> with vendored gems vs. bundler.
>>
>> On Wed, May 18, 2011 at 4:33 PM, Brian Guthrie
>> <bguthrie at thoughtworks.com> wrote:
>>> If you specify a dependency on a binary gem, and attempt to lock your
>>> project to that gem, Bundler will lock the version that's valid for
>>> your current platform but not every conceivable platform. I consider
>>> this a major flaw in their locking model, but I believe this may get
>>> fixed in 1.1. I'll give it a shot in Windows today if I get the
>>> chance. If everything looks okay, I'll try checking in the lockfile.
>>>
>>> Brian
>>>
>>> On Thu, May 19, 2011 at 8:31 AM, Chad Woolley <thewoolleyman at gmail.com> wrote:
>>>> Not checking in Gemfile.lock seems like a bad idea. ?This allows
>>>> unspecified/indirect dependencies to float, which is almost guaranteed
>>>> to cause breakages as the world moves on.
>>>>
>>>> On Wed, May 18, 2011 at 2:47 PM, Brian Guthrie
>>>> <bguthrie at thoughtworks.com> wrote:
>>>>> To the best of my knowledge, we do not have any dependencies on binary
>>>>> gems at the moment. But even if we did, I don't see why it should be a
>>>>> problem as long as Windows equivalents for those gems exist. I agree
>>>>> that there's an expectation that CC.rb should be as widely compatible
>>>>> as possible. I haven't had a chance to test every platform since the
>>>>> upgrade, but I'm trying to remain true to the spirit of that goal.
>>>>>
>>>>> But I don't see any good reason for the expectation that a Windows
>>>>> user should be able to check out _the source code_ and immediately run
>>>>> it. If they check out the source code, they can bundle install like
>>>>> any other Ruby developer. If they install it as a gem, then let gem
>>>>> dependencies be handled and installed as per normal. Either case would
>>>>> handle binary gems just fine.
>>>>>
>>>>> But if they just want a dependency-free _binary download_, there's no
>>>>> reason why we can't package a zipfile that includes all dependencies
>>>>> (using bundle install --deployment, for example) and make that
>>>>> available. Such an artifact should be the output of a potential
>>>>> Windows release build.
>>>>>
>>>>> You may have noticed that I haven't checked in a Gemfile.lock either.
>>>>> In case you were wondering why, it's because the last time I tried to
>>>>> use Bundler on a cross-platform project (fairly recently--six months
>>>>> ago or so) it failed to lock down dependencies in a platform-agnostic
>>>>> way. This probably isn't an issue now, because there are no binary
>>>>> gems, and so perhaps we should reconsider. But it would be if there
>>>>> were.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Brian
>>>>>
>>>>> On Thu, May 19, 2011 at 6:17 AM, Chad Woolley <thewoolleyman at gmail.com> wrote:
>>>>>> If we use bundler with packaged gems (which we should, if we aren't),
>>>>>> that's essentially the same as vendoring them, which is what we did
>>>>>> before.
>>>>>>
>>>>>> Agreed on avoiding use of binary gems. ?Are we using any? ?If so, we
>>>>>> should use a non-binary equivalent if at all possible.
>>>>>>
>>>>>> On Wed, May 18, 2011 at 8:51 AM, Alexey Verkhovsky
>>>>>> <alexey.verkhovsky at gmail.com> wrote:
>>>>>>> I do have a rather strong opinion that it should not use binary gems. This
>>>>>>> adds a big barrier to entry, especially on Windoze.
>>>>>>>
>>>>>>> On Wed, May 18, 2011 at 9:46 AM, Alexey Verkhovsky
>>>>>>> <alexey.verkhovsky at gmail.com> wrote:
>>>>>>>>
>>>>>>>> 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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Alexey Verkhovsky
>>>>>>> http://alex-verkhovsky.blogspot.com/
>>>>>>> CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Cruisecontrolrb-developers mailing list
>>>>>>> Cruisecontrolrb-developers at rubyforge.org
>>>>>>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Cruisecontrolrb-developers mailing list
>>>>>> Cruisecontrolrb-developers at rubyforge.org
>>>>>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>>>>>
>>>>> _______________________________________________
>>>>> Cruisecontrolrb-developers mailing list
>>>>> Cruisecontrolrb-developers at rubyforge.org
>>>>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>>>>
>>>> _______________________________________________
>>>> Cruisecontrolrb-developers mailing list
>>>> Cruisecontrolrb-developers at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>>>
>>> _______________________________________________
>>> Cruisecontrolrb-developers mailing list
>>> Cruisecontrolrb-developers at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>>
>> _______________________________________________
>> Cruisecontrolrb-developers mailing list
>> Cruisecontrolrb-developers at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>>
> _______________________________________________
> Cruisecontrolrb-developers mailing list
> Cruisecontrolrb-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>

From alexey.verkhovsky at gmail.com  Thu May 19 12:09:41 2011
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Thu, 19 May 2011 10:09:41 -0600
Subject: [Cruisecontrolrb-developers] Why there was no bundle in CC.rb
 originally (and probably still shouldn't be now)
In-Reply-To: <BANLkTikC2iDrdXcqy-Zwo9zEPy7MMO10zA@mail.gmail.com>
References: <BANLkTimFtzoAG8=Anm6-g47Y4fwbt9WnWg@mail.gmail.com>
	<BANLkTim-YO4O=GazjNs9ivQiWsL-xf=x4g@mail.gmail.com>
	<BANLkTimF9Ebhd998hHfQrJwsJgw+Z8fQsw@mail.gmail.com>
	<BANLkTikC2iDrdXcqy-Zwo9zEPy7MMO10zA@mail.gmail.com>
Message-ID: <BANLkTimrWzE00d5YPu8g99_cpJTS+LxzsQ@mail.gmail.com>

On Wed, May 18, 2011 at 3:47 PM, Brian Guthrie <bguthrie at thoughtworks.com>wrote:

> To the best of my knowledge, we do not have any dependencies on binary
> gems at the moment.


nokogiri

Not all CC.rb users are Ruby developers. At least, this used to be the case
when I kept awareness of such things.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/cruisecontrolrb-developers/attachments/20110519/5b2d85a2/attachment-0001.html>

From bguthrie at thoughtworks.com  Thu May 19 15:50:47 2011
From: bguthrie at thoughtworks.com (Brian Guthrie)
Date: Fri, 20 May 2011 05:50:47 +1000
Subject: [Cruisecontrolrb-developers] Why there was no bundle in CC.rb
 originally (and probably still shouldn't be now)
In-Reply-To: <BANLkTik41PK4H7HuZ+Vno8_3QaRt4oYtqg@mail.gmail.com>
References: <BANLkTimFtzoAG8=Anm6-g47Y4fwbt9WnWg@mail.gmail.com>
	<BANLkTim-YO4O=GazjNs9ivQiWsL-xf=x4g@mail.gmail.com>
	<BANLkTimF9Ebhd998hHfQrJwsJgw+Z8fQsw@mail.gmail.com>
	<BANLkTikC2iDrdXcqy-Zwo9zEPy7MMO10zA@mail.gmail.com>
	<BANLkTinAVhoL2TdudpXRuTPz8vCPLNWkag@mail.gmail.com>
	<BANLkTin0HUjbbn1HjrKUBqA1b5eex5GTwQ@mail.gmail.com>
	<BANLkTikWk=KSWa0Cac9tMuXDXG9TjkbEYA@mail.gmail.com>
	<BANLkTikNfXvOH=od=qtatn_+mzYxoEQ5Mw@mail.gmail.com>
	<BANLkTik41PK4H7HuZ+Vno8_3QaRt4oYtqg@mail.gmail.com>
Message-ID: <BANLkTikq7t=NRZc9uFHN+-UZQuo1kPjpTA@mail.gmail.com>

On Thu, May 19, 2011 at 12:24 PM, Chad Woolley <thewoolleyman at gmail.com> wrote:
> "I'd prefer to continue to use Bundler and vendor everything on demand
> for things that need it, like self-contained releases." - not positive
> what that means, but it sounds like it could be good :)

task :release => :test
 ?`bundle install --deployment`
 ?`gem package`
 ?`gem push ccrb-#{RUBY-PLATFORM}.gem`
end

Something like that. Replace gem package with tar and zip for non-gem
Linux and Windows releases respectively if needed.

I've looked into binary gems. Nokogiri has crept into the gemfile via
Mechanize (which I believe exists for the performance build, which I'm
not currently maintaining - any volunteers?). It can be eliminated as
a dependency by removing mechanize and adding Builder explicitly as a
dependency. This still leaves many failing tests, which I haven't
begun to look into. Do we have some idea of how many Windows users
CC.rb has?

Apparently there is now a way to build many C-based gems in Windows
(see https://github.com/oneclick/rubyinstaller) and so one could
conceivably run a Windows release task on a Windows box that built the
necessary binaries on demand and automatically uploaded them to the
main CC.rb site.

Cheers,

Brian

From alexey.verkhovsky at gmail.com  Thu May 19 16:22:55 2011
From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky)
Date: Thu, 19 May 2011 14:22:55 -0600
Subject: [Cruisecontrolrb-developers] Why there was no bundle in CC.rb
 originally (and probably still shouldn't be now)
In-Reply-To: <BANLkTikq7t=NRZc9uFHN+-UZQuo1kPjpTA@mail.gmail.com>
References: <BANLkTimFtzoAG8=Anm6-g47Y4fwbt9WnWg@mail.gmail.com>
	<BANLkTim-YO4O=GazjNs9ivQiWsL-xf=x4g@mail.gmail.com>
	<BANLkTimF9Ebhd998hHfQrJwsJgw+Z8fQsw@mail.gmail.com>
	<BANLkTikC2iDrdXcqy-Zwo9zEPy7MMO10zA@mail.gmail.com>
	<BANLkTinAVhoL2TdudpXRuTPz8vCPLNWkag@mail.gmail.com>
	<BANLkTin0HUjbbn1HjrKUBqA1b5eex5GTwQ@mail.gmail.com>
	<BANLkTikWk=KSWa0Cac9tMuXDXG9TjkbEYA@mail.gmail.com>
	<BANLkTikNfXvOH=od=qtatn_+mzYxoEQ5Mw@mail.gmail.com>
	<BANLkTik41PK4H7HuZ+Vno8_3QaRt4oYtqg@mail.gmail.com>
	<BANLkTikq7t=NRZc9uFHN+-UZQuo1kPjpTA@mail.gmail.com>
Message-ID: <BANLkTimBvMDJZeU6xKbUitcFdfQizQBU1Q@mail.gmail.com>

On Thu, May 19, 2011 at 1:50 PM, Brian Guthrie <bguthrie at thoughtworks.com>wrote:

> Do we have some idea of how many Windows users CC.rb has?
>

Not many.


> Apparently there is now a way to build many C-based gems in Windows
> (see https://github.com/oneclick/rubyinstaller) and so one could
> conceivably run a Windows release task on a Windows box that built the
> necessary binaries on demand and automatically uploaded them to the
> main CC.rb site.
>

Would be a great idea for a *very seriously* supported project. For an
open-source project that sees a bit of ongoing development every once in a
while, you don't want to maintain complex infrastructure of this sort. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/cruisecontrolrb-developers/attachments/20110519/e262c98f/attachment.html>

From ckponnappa at gmail.com  Thu May 19 18:54:04 2011
From: ckponnappa at gmail.com (Sidu Ponnappa)
Date: Fri, 20 May 2011 04:24:04 +0530
Subject: [Cruisecontrolrb-developers] Why there was no bundle in CC.rb
 originally (and probably still shouldn't be now)
In-Reply-To: <BANLkTimBvMDJZeU6xKbUitcFdfQizQBU1Q@mail.gmail.com>
References: <BANLkTimFtzoAG8=Anm6-g47Y4fwbt9WnWg@mail.gmail.com>
	<BANLkTim-YO4O=GazjNs9ivQiWsL-xf=x4g@mail.gmail.com>
	<BANLkTimF9Ebhd998hHfQrJwsJgw+Z8fQsw@mail.gmail.com>
	<BANLkTikC2iDrdXcqy-Zwo9zEPy7MMO10zA@mail.gmail.com>
	<BANLkTinAVhoL2TdudpXRuTPz8vCPLNWkag@mail.gmail.com>
	<BANLkTin0HUjbbn1HjrKUBqA1b5eex5GTwQ@mail.gmail.com>
	<BANLkTikWk=KSWa0Cac9tMuXDXG9TjkbEYA@mail.gmail.com>
	<BANLkTikNfXvOH=od=qtatn_+mzYxoEQ5Mw@mail.gmail.com>
	<BANLkTik41PK4H7HuZ+Vno8_3QaRt4oYtqg@mail.gmail.com>
	<BANLkTikq7t=NRZc9uFHN+-UZQuo1kPjpTA@mail.gmail.com>
	<BANLkTimBvMDJZeU6xKbUitcFdfQizQBU1Q@mail.gmail.com>
Message-ID: <BANLkTikstd_ymxEJeXRteLWK71S8iggY0g@mail.gmail.com>

Would it be fair to support Windows only via JRuby? That would make
life much easier for you.

Best,
Sidu.
http://c42.in

On 20 May 2011 01:52, Alexey Verkhovsky <alexey.verkhovsky at gmail.com> wrote:
> On Thu, May 19, 2011 at 1:50 PM, Brian Guthrie <bguthrie at thoughtworks.com>
> wrote:
>>
>> Do we have some idea of how many Windows users CC.rb has?
>
> Not many.
>
>>
>> Apparently there is now a way to build many C-based gems in Windows
>> (see https://github.com/oneclick/rubyinstaller) and so one could
>> conceivably run a Windows release task on a Windows box that built the
>> necessary binaries on demand and automatically uploaded them to the
>> main CC.rb site.
>
> Would be a great idea for a *very seriously* supported project. For an
> open-source project that sees a bit of ongoing development every once in a
> while, you don't want to maintain complex infrastructure of this sort. :)
>
> _______________________________________________
> Cruisecontrolrb-developers mailing list
> Cruisecontrolrb-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>
>

From bguthrie at thoughtworks.com  Sun May 22 05:56:59 2011
From: bguthrie at thoughtworks.com (Brian Guthrie)
Date: Sun, 22 May 2011 19:56:59 +1000
Subject: [Cruisecontrolrb-developers] Improving cross-platform support for
 process creation & destruction (was: Why there was no bundle in CC.rb
 originally)
Message-ID: <BANLkTimoyQeGv6C1ixm-a8_fCxsqgof3OA@mail.gmail.com>

On Fri, May 20, 2011 at 8:54 AM, Sidu Ponnappa <ckponnappa at gmail.com> 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?

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

From bguthrie at thoughtworks.com  Sun May 22 05:59:12 2011
From: bguthrie at thoughtworks.com (Brian Guthrie)
Date: Sun, 22 May 2011 19:59:12 +1000
Subject: [Cruisecontrolrb-developers] Why there was no bundle in CC.rb
 originally (and probably still shouldn't be now)
In-Reply-To: <BANLkTimBvMDJZeU6xKbUitcFdfQizQBU1Q@mail.gmail.com>
References: <BANLkTimFtzoAG8=Anm6-g47Y4fwbt9WnWg@mail.gmail.com>
	<BANLkTim-YO4O=GazjNs9ivQiWsL-xf=x4g@mail.gmail.com>
	<BANLkTimF9Ebhd998hHfQrJwsJgw+Z8fQsw@mail.gmail.com>
	<BANLkTikC2iDrdXcqy-Zwo9zEPy7MMO10zA@mail.gmail.com>
	<BANLkTinAVhoL2TdudpXRuTPz8vCPLNWkag@mail.gmail.com>
	<BANLkTin0HUjbbn1HjrKUBqA1b5eex5GTwQ@mail.gmail.com>
	<BANLkTikWk=KSWa0Cac9tMuXDXG9TjkbEYA@mail.gmail.com>
	<BANLkTikNfXvOH=od=qtatn_+mzYxoEQ5Mw@mail.gmail.com>
	<BANLkTik41PK4H7HuZ+Vno8_3QaRt4oYtqg@mail.gmail.com>
	<BANLkTikq7t=NRZc9uFHN+-UZQuo1kPjpTA@mail.gmail.com>
	<BANLkTimBvMDJZeU6xKbUitcFdfQizQBU1Q@mail.gmail.com>
Message-ID: <BANLkTiksKrbjs-YMX2=UtPAd+pEW68eEFg@mail.gmail.com>

On Fri, May 20, 2011 at 6:22 AM, Alexey Verkhovsky
<alexey.verkhovsky at gmail.com> wrote:
> On Thu, May 19, 2011 at 1:50 PM, Brian Guthrie <bguthrie at thoughtworks.com>
> wrote:
>>
>> Do we have some idea of how many Windows users CC.rb has?
>
> Not many.
>
>>
>> Apparently there is now a way to build many C-based gems in Windows
>> (see https://github.com/oneclick/rubyinstaller) and so one could
>> conceivably run a Windows release task on a Windows box that built the
>> necessary binaries on demand and automatically uploaded them to the
>> main CC.rb site.
>
> Would be a great idea for a *very seriously* supported project. For an
> open-source project that sees a bit of ongoing development every once in a
> while, you don't want to maintain complex infrastructure of this sort. :)

That's a good point, although I hasten to add that I wasn't
_seriously_ planning on building binaries on Windows; I just thought
it was interesting that it existed at all. :) I'll plan on ridding the
Gemfile of Nokogiri the next chance I get, and get Windows tests
running properly, and that should in principle eliminate the need for
a separate build box.

Cheers,

Brian