CC.rb upgrades and maintenance

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

CC.rb upgrades and maintenance

Brian Guthrie-3
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
_______________________________________________
Cruisecontrolrb-developers mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
Reply | Threaded
Open this post in threaded view
|

Re: CC.rb upgrades and maintenance

Chad Woolley
On Wed, May 4, 2011 at 1:16 AM, Brian Guthrie <[hidden email]> 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
[hidden email]
http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
Reply | Threaded
Open this post in threaded view
|

Re: CC.rb upgrades and maintenance

Brian Guthrie-3
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 <[hidden email]> wrote:

> On Wed, May 4, 2011 at 1:16 AM, Brian Guthrie <[hidden email]> 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
> [hidden email]
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>
_______________________________________________
Cruisecontrolrb-developers mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
Reply | Threaded
Open this post in threaded view
|

Re: CC.rb upgrades and maintenance

Chad Woolley
On Thu, May 5, 2011 at 12:39 AM, Brian Guthrie
<[hidden email]> 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
[hidden email]
http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
Reply | Threaded
Open this post in threaded view
|

Re: CC.rb upgrades and maintenance

Brian Guthrie-3
Should it immediately restart the builder afterwards?

On Fri, May 6, 2011 at 2:27 PM, Chad Woolley <[hidden email]> wrote:

> On Thu, May 5, 2011 at 12:39 AM, Brian Guthrie
> <[hidden email]> 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
> [hidden email]
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>
_______________________________________________
Cruisecontrolrb-developers mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
Reply | Threaded
Open this post in threaded view
|

Re: CC.rb upgrades and maintenance

Chad Woolley
On Thu, May 5, 2011 at 10:50 PM, Brian Guthrie
<[hidden email]> wrote:
> Should it immediately restart the builder afterwards?
>
Right, I guess it's really a "restart build(er)" button...
_______________________________________________
Cruisecontrolrb-developers mailing list
[hidden email]
http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers