From ArishAhsan at gmail.com  Sat Dec  6 00:48:26 2008
From: ArishAhsan at gmail.com (ArishAhsan)
Date: Fri, 5 Dec 2008 21:48:26 -0800 (PST)
Subject: [Cruisecontrolrb-developers]  How to Add Tab in Dash board
Message-ID: <20851404.post@talk.nabble.com>


Hi,
How we can add tabs in dash board in cruise control ? I want to add few more
tabs under 
dashboard->buid tab.



-- 
View this message in context: http://www.nabble.com/How-to-Add-Tab-in-Dash-board-tp20851404p20851404.html
Sent from the CruiseControl.rb - Development mailing list archive at Nabble.com.


From jacob.kjeldahl at gmail.com  Tue Dec  9 03:36:24 2008
From: jacob.kjeldahl at gmail.com (Jacob Kjeldahl)
Date: Tue, 9 Dec 2008 09:36:24 +0100
Subject: [Cruisecontrolrb-developers] The rationale behind using mtime(build
	directory) as timestamp
Message-ID: <4c9dc4270812090036k323f745cx8f485a1d7bd12440@mail.gmail.com>

Hello

The short story is that I have build a plugin for reporting changes to code
coverage. It basically looks at the current builds artifacts and the last
successful builds artifact and generates a simple report showing the
differences in code coverage and number of lines.

The problem arose when I decided to run the plugin for all builds. I open
the console and for each build of a project I called the build_finished
method of my plugin. It almost worked like a charm. The reports where
generated, but the timestamps of the builds were messed up.

So looking through the code I found the timestamp method in build_status.rb
and it does what the commit log below specifies.

My question is: Why are you looking at mtime(build directory)? It changes if
files are added to the directory later. I understand that the build.log
might be missing, but even if it is there the directory mtime is used as
timestamp.

commit d0bdcfcc11f0899f46b7744cfd820e9b70c37ac1
Author: Jeff Xiong <gigix1980 at gmail.com>
Date:   Wed Mar 14 08:13:59 2007 +0000

    r354: builds timestamped based on max(mtime(build.log), mtime(build
directory)

Best regards Jacob Kjeldahl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/cruisecontrolrb-developers/attachments/20081209/d3acdb84/attachment.html>

From gigix1980 at gmail.com  Tue Dec  9 03:54:47 2008
From: gigix1980 at gmail.com (Jeff Xiong)
Date: Tue, 9 Dec 2008 16:54:47 +0800
Subject: [Cruisecontrolrb-developers] The rationale behind using
	mtime(build directory) as timestamp
In-Reply-To: <4c9dc4270812090036k323f745cx8f485a1d7bd12440@mail.gmail.com>
References: <4c9dc4270812090036k323f745cx8f485a1d7bd12440@mail.gmail.com>
Message-ID: <20fd9dc50812090054t2228e4bfl941c7cf32a70bef3@mail.gmail.com>

I remember that was because we assume the build directory would be
frozen after done the corresponding build: the artifacts would be left
there AS-IS and unchanged. Adding a timestamp would be a solution if
the assumption has been proven invalid.

On Tue, Dec 9, 2008 at 4:36 PM, Jacob Kjeldahl <jacob.kjeldahl at gmail.com> wrote:
> Hello
>
> The short story is that I have build a plugin for reporting changes to code
> coverage. It basically looks at the current builds artifacts and the last
> successful builds artifact and generates a simple report showing the
> differences in code coverage and number of lines.
>
> The problem arose when I decided to run the plugin for all builds. I open
> the console and for each build of a project I called the build_finished
> method of my plugin. It almost worked like a charm. The reports where
> generated, but the timestamps of the builds were messed up.
>
> So looking through the code I found the timestamp method in build_status.rb
> and it does what the commit log below specifies.
>
> My question is: Why are you looking at mtime(build directory)? It changes if
> files are added to the directory later. I understand that the build.log
> might be missing, but even if it is there the directory mtime is used as
> timestamp.
>
> commit d0bdcfcc11f0899f46b7744cfd820e9b70c37ac1
> Author: Jeff Xiong <gigix1980 at gmail.com>
> Date:   Wed Mar 14 08:13:59 2007 +0000
>
>     r354: builds timestamped based on max(mtime(build.log), mtime(build
> directory)
>
> Best regards Jacob Kjeldahl
>
> _______________________________________________
> Cruisecontrolrb-developers mailing list
> Cruisecontrolrb-developers at rubyforge.org
> http://rubyforge.org/mailman/listinfo/cruisecontrolrb-developers
>
>



-- 
Jeff Xiong
Software Journeyman - http://gigix.thoughtworkers.org
Open Source Contributor - http://fluorida.googlecode.com/
Technical Evangelist - http://www.infoq.com/cn/

From thewoolleyman at gmail.com  Sat Dec 27 00:39:37 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Fri, 26 Dec 2008 22:39:37 -0700
Subject: [Cruisecontrolrb-developers] Git project building over and over
	even though there are no commits
In-Reply-To: <e3af97510811190209j63ef6838uf84de673b62a2abb@mail.gmail.com>
References: <e3af97510811121228g420a147fq3e63c9d8e0893776@mail.gmail.com>
	<e3af97510811190209j63ef6838uf84de673b62a2abb@mail.gmail.com>
Message-ID: <e3af97510812262139m3d63f0c9idb4a872d3c30781d@mail.gmail.com>

ffmike stepped up and patched this one, seems to be working for me in
my branch, which also includes an (imperfect) fix for the bad return
code detection:

http://github.com/thewoolleyman/cruisecontrol.rb/tree/master


On Wed, Nov 19, 2008 at 3:09 AM, Chad Woolley <thewoolleyman at gmail.com> wrote:
> Found the root cause of this (short commit IDs are not unique, and ccrb
> still doesn't detect bad return codes from source control commands):
>
> http://cruisecontrolrb.lighthouseapp.com/projects/9150-cruise-control-rb/tickets/221-git-error-short-commit-ids-are-not-always-unique
>
> On Wed, Nov 12, 2008 at 1:28 PM, Chad Woolley <thewoolleyman at gmail.com>
> wrote:
>>
>> Updating to latest ccrb trunk didn't help, restarting cruise/box didn't
>> work - it just builds every 5 minutes.  Working copy looks clean.
>>
>> Anyone seen this?
>>
>> This is on the new Rails CI server, if anyone wants to help debug it I can
>> give access.  I don't have time right now, waiting to see if it goes away on
>> the next commit.
>>
>> -- Chad
>
>