cruisecontrol-user

Re: [Cruisecontrol-user] Two questions

[Dan R. <dan...@gm...>]

Subject: [Cruisecontrol-user] Two questions
To: <cru...@li...>

I have two quick questions I'd like to bounce off the user group before
diving in to fix these two problems - has anyone else encountered these
hang-ups as well?



1 - check scm if there are changes prior to going to queued state - is
there any penalty to checking first before putting a build into queued?

2 - don't calculate a waiting state as "build time" - our queued builds
tend to compound this time with actual build time and consider it all
"building" time.



We're using CC in distributed mode and a single agent is earmarked for
the "faster" builds of the group, until we increased our agent count
above what's available.  This can result in CC calculating build times
well beyond actual build times as builds in a holding pattern waiting
for an agent to become available consider that hold time as part of the
regular build.



Hi EJ,

If I understand your two questions, they are really one: How to get 
accurate "build time" when using CCDist?

I ran into this same issue before when looking at some of the Jira 
issues related to stats reporting:
http://jira.public.thoughtworks.org/browse/CC-475

The solution for CCDist I was thinking about was to add a new "State" 
(defined in net.sourceforge.cruisecontrol.ProjectState) for projects.

Currently, a typical project goes through:
WAITING
QUEUED
BOOTSTRAPPING
MODIFICATIONSET
BUILDING- here is where build times go nuts, as we stay in this state 
while looking for an available agent.
MERGING_LOGS
PUBLISHING
wash, rinse, repeat.

I was thinking about:
WAITING
QUEUED
BOOTSTRAPPING
MODIFICATIONSET
PREBUILD - this would be the new state.
BUILDING
MERGING_LOGS
PUBLISHING
wash, rinse, repeat.

Easy right? Now the bad news: Project impl sets the state to BUILDING 
before calling Builder.build(), thus there is no clean way to move to 
PREBUILD before we're already in the BUILDING state. See Project.build() 
for details.

Also, if we change Project.build() to call a new Builder.preBuild() 
method before calling Builder.build(), the CCDist case/impl of 
preBuild() really needs to find and hold an available agent AND somehow 
return that agent from the .preBuild() call AND now Builder.build() has 
to pass that agent in to the Builder.build() call... it gets messy fast.

If we find a good design to solve the mess above, the effect on 
non-CCDist builds would be simply that each build goes from PREBUILD to 
BUILDING immediately. I don't think that is a big deal. The real 
challenge is cleanly altering the State system without introducing a ton 
of coupling, nor requiring changes to all existing Builder impls...

I'm open to ideas on better ways to handle this. Also, I didn't dig into 
how the actual build times are created (to make sure the whole 
"PREBUILD" state idea would actually solve this). Maybe the details of 
how the build times work could shed light on another approach.

Thoughts?

Dan

Re: [Cruisecontrol-user] Two questions

[Dan R. <dan...@gm...>]

Subject: Re: Two questions

I think we had cruft lying around in our tomcat's work directory.

Cleaning that up seems to have made a difference.

I'd still bet that people will continue to ask, why not just have the
status reflect what the hover says instead of just saying, "building
(<time>)"?

I guess we could just set our version to do that by default.

/shrug


Hi EJ,

Glad you got if solved.

Feel free to create a Jira and attach a patch (ideally including unit 
test) to change the reporting/jsp summary page to have a new column for 
"Progress" showing the tooltip message.

I didn't mean to imply changing this is not an option, just wanted to 
let you know what's already in there...

Dan

Re: [Cruisecontrol-user] Two questions

[EJ C. <ejc...@up...>]

Uggg - that ramped up fast - I was thinking, why not have the status
that's on the build page be written out to the buildstatus.txt file.
Even just simply showing exactly what the build thread is doing while
its doing it would be better than the main page of the reporting app
saying "Building" and the project specific page saying "Waiting for
agent of type...".

Additionally, moving this info from the deeper page to the higher level
main page would stop people from going into each project page and
hitting refresh and having tomcat send back what can sometimes be a
massive build result page (of the last build).  Since this page also
shows all the changes, sometimes it shows two or three integrations
(with thousands of files in each changelist).

Ideally, yeah, we wouldn't have the "building since" show the start of
the build (which starts with trying to find an agent) and we'd also not
even put something in queue if there weren't any changes in perforce,
but just pushing up the info so people can see (without asking releng a
million times) what exactly is happening.

Does this sound crazy?  Thanks for replying Dan!!

-----Original Message-----
From: Dan Rollo [mailto:dan...@gm...] 
Sent: Thursday, June 26, 2008 1:11 AM
To: cru...@li...; EJ Ciramella
Subject: Re: [Cruisecontrol-user] Two questions

Subject: [Cruisecontrol-user] Two questions
To: <cru...@li...>

I have two quick questions I'd like to bounce off the user group before
diving in to fix these two problems - has anyone else encountered these
hang-ups as well?



1 - check scm if there are changes prior to going to queued state - is
there any penalty to checking first before putting a build into queued?

2 - don't calculate a waiting state as "build time" - our queued builds
tend to compound this time with actual build time and consider it all
"building" time.



We're using CC in distributed mode and a single agent is earmarked for
the "faster" builds of the group, until we increased our agent count
above what's available.  This can result in CC calculating build times
well beyond actual build times as builds in a holding pattern waiting
for an agent to become available consider that hold time as part of the
regular build.



Hi EJ,

If I understand your two questions, they are really one: How to get 
accurate "build time" when using CCDist?

I ran into this same issue before when looking at some of the Jira 
issues related to stats reporting:
http://jira.public.thoughtworks.org/browse/CC-475

The solution for CCDist I was thinking about was to add a new "State" 
(defined in net.sourceforge.cruisecontrol.ProjectState) for projects.

Currently, a typical project goes through:
WAITING
QUEUED
BOOTSTRAPPING
MODIFICATIONSET
BUILDING- here is where build times go nuts, as we stay in this state 
while looking for an available agent.
MERGING_LOGS
PUBLISHING
wash, rinse, repeat.

I was thinking about:
WAITING
QUEUED
BOOTSTRAPPING
MODIFICATIONSET
PREBUILD - this would be the new state.
BUILDING
MERGING_LOGS
PUBLISHING
wash, rinse, repeat.

Easy right? Now the bad news: Project impl sets the state to BUILDING 
before calling Builder.build(), thus there is no clean way to move to 
PREBUILD before we're already in the BUILDING state. See Project.build()

for details.

Also, if we change Project.build() to call a new Builder.preBuild() 
method before calling Builder.build(), the CCDist case/impl of 
preBuild() really needs to find and hold an available agent AND somehow 
return that agent from the .preBuild() call AND now Builder.build() has 
to pass that agent in to the Builder.build() call... it gets messy fast.

If we find a good design to solve the mess above, the effect on 
non-CCDist builds would be simply that each build goes from PREBUILD to 
BUILDING immediately. I don't think that is a big deal. The real 
challenge is cleanly altering the State system without introducing a ton

of coupling, nor requiring changes to all existing Builder impls...

I'm open to ideas on better ways to handle this. Also, I didn't dig into

how the actual build times are created (to make sure the whole 
"PREBUILD" state idea would actually solve this). Maybe the details of 
how the build times work could shed light on another approach.

Thoughts?

Dan

Re: [Cruisecontrol-user] Two questions

[Dan R. <dan...@gm...>]

> -----Original Message-----
> From: Dan Rollo [mailto:dan...@gm...] 
> Sent: Thursday, June 26, 2008 1:11 AM
> To: cru...@li...; EJ Ciramella
> Subject: Re: [Cruisecontrol-user] Two questions
> 
> Subject: [Cruisecontrol-user] Two questions
> To: <cru...@li...>
> 
> I have two quick questions I'd like to bounce off the user group before
> diving in to fix these two problems - has anyone else encountered these
> hang-ups as well?
> 
> 
> 
> 1 - check scm if there are changes prior to going to queued state - is
> there any penalty to checking first before putting a build into queued?
> 
> 2 - don't calculate a waiting state as "build time" - our queued builds
> tend to compound this time with actual build time and consider it all
> "building" time.
> 
> 
> 
> We're using CC in distributed mode and a single agent is earmarked for
> the "faster" builds of the group, until we increased our agent count
> above what's available.  This can result in CC calculating build times
> well beyond actual build times as builds in a holding pattern waiting
> for an agent to become available consider that hold time as part of the
> regular build.
> 
> 
> 
> Hi EJ,
> 
> If I understand your two questions, they are really one: How to get 
> accurate "build time" when using CCDist?
> 
> I ran into this same issue before when looking at some of the Jira 
> issues related to stats reporting:
> http://jira.public.thoughtworks.org/browse/CC-475
> 
> The solution for CCDist I was thinking about was to add a new "State" 
> (defined in net.sourceforge.cruisecontrol.ProjectState) for projects.
> 
> Currently, a typical project goes through:
> WAITING
> QUEUED
> BOOTSTRAPPING
> MODIFICATIONSET
> BUILDING- here is where build times go nuts, as we stay in this state 
> while looking for an available agent.
> MERGING_LOGS
> PUBLISHING
> wash, rinse, repeat.
> 
> I was thinking about:
> WAITING
> QUEUED
> BOOTSTRAPPING
> MODIFICATIONSET
> PREBUILD - this would be the new state.
> BUILDING
> MERGING_LOGS
> PUBLISHING
> wash, rinse, repeat.
> 
> Easy right? Now the bad news: Project impl sets the state to BUILDING 
> before calling Builder.build(), thus there is no clean way to move to 
> PREBUILD before we're already in the BUILDING state. See Project.build()
> 
> for details.
> 
> Also, if we change Project.build() to call a new Builder.preBuild() 
> method before calling Builder.build(), the CCDist case/impl of 
> preBuild() really needs to find and hold an available agent AND somehow 
> return that agent from the .preBuild() call AND now Builder.build() has 
> to pass that agent in to the Builder.build() call... it gets messy fast.
> 
> If we find a good design to solve the mess above, the effect on 
> non-CCDist builds would be simply that each build goes from PREBUILD to 
> BUILDING immediately. I don't think that is a big deal. The real 
> challenge is cleanly altering the State system without introducing a ton
> 
> of coupling, nor requiring changes to all existing Builder impls...
> 
> I'm open to ideas on better ways to handle this. Also, I didn't dig into
> 
> how the actual build times are created (to make sure the whole 
> "PREBUILD" state idea would actually solve this). Maybe the details of 
> how the build times work could shed light on another approach.
> 
> Thoughts?
> 
> Dan
> 
> 
> 

EJ Ciramella wrote:
> Uggg - that ramped up fast - I was thinking, why not have the status
> that's on the build page be written out to the buildstatus.txt file.
> Even just simply showing exactly what the build thread is doing while
> its doing it would be better than the main page of the reporting app
> saying "Building" and the project specific page saying "Waiting for
> agent of type...".
>
> Additionally, moving this info from the deeper page to the higher level
> main page would stop people from going into each project page and
> hitting refresh and having tomcat send back what can sometimes be a
> massive build result page (of the last build).  Since this page also
> shows all the changes, sometimes it shows two or three integrations
> (with thousands of files in each changelist).
>
> Ideally, yeah, we wouldn't have the "building since" show the start of
> the build (which starts with trying to find an agent) and we'd also not
> even put something in queue if there weren't any changes in perforce,
> but just pushing up the info so people can see (without asking releng a
> million times) what exactly is happening.
>
> Does this sound crazy?  Thanks for replying Dan!!
>


(Reordered your reply to maintain thought train).
EJ,

Yeah, this little thing gets dicey fast. The good news is the feature
you just asked for is already in place (in the last couple releases
even). If you see the "progress message" in the individual build pages
(like: "finding agent with entries:"), then the same info is already
available on the higher level summary page: It shows as a tooltip if you
hover over the "Status (since)"

Dan

Re: [Cruisecontrol-user] Two questions

[EJ C. <ejc...@up...>]

Hover vs. display - I'd lean toward display.

Either way, I'm not getting that in 2.7.2 with firefox/ie/safari.  I'm
hovering over the "building since" text in the row of the build that is
running.

Am I missing something?

-----Original Message-----
From: Dan Rollo [mailto:dan...@gm...] 
Sent: Thursday, June 26, 2008 11:55 AM
To: EJ Ciramella
Cc: cru...@li...
Subject: Re: [Cruisecontrol-user] Two questions


> -----Original Message-----
> From: Dan Rollo [mailto:dan...@gm...] 
> Sent: Thursday, June 26, 2008 1:11 AM
> To: cru...@li...; EJ Ciramella
> Subject: Re: [Cruisecontrol-user] Two questions
> 
> Subject: [Cruisecontrol-user] Two questions
> To: <cru...@li...>
> 
> I have two quick questions I'd like to bounce off the user group
before
> diving in to fix these two problems - has anyone else encountered
these
> hang-ups as well?
> 
> 
> 
> 1 - check scm if there are changes prior to going to queued state - is
> there any penalty to checking first before putting a build into
queued?
> 
> 2 - don't calculate a waiting state as "build time" - our queued
builds
> tend to compound this time with actual build time and consider it all
> "building" time.
> 
> 
> 
> We're using CC in distributed mode and a single agent is earmarked for
> the "faster" builds of the group, until we increased our agent count
> above what's available.  This can result in CC calculating build times
> well beyond actual build times as builds in a holding pattern waiting
> for an agent to become available consider that hold time as part of
the
> regular build.
> 
> 
> 
> Hi EJ,
> 
> If I understand your two questions, they are really one: How to get 
> accurate "build time" when using CCDist?
> 
> I ran into this same issue before when looking at some of the Jira 
> issues related to stats reporting:
> http://jira.public.thoughtworks.org/browse/CC-475
> 
> The solution for CCDist I was thinking about was to add a new "State" 
> (defined in net.sourceforge.cruisecontrol.ProjectState) for projects.
> 
> Currently, a typical project goes through:
> WAITING
> QUEUED
> BOOTSTRAPPING
> MODIFICATIONSET
> BUILDING- here is where build times go nuts, as we stay in this state 
> while looking for an available agent.
> MERGING_LOGS
> PUBLISHING
> wash, rinse, repeat.
> 
> I was thinking about:
> WAITING
> QUEUED
> BOOTSTRAPPING
> MODIFICATIONSET
> PREBUILD - this would be the new state.
> BUILDING
> MERGING_LOGS
> PUBLISHING
> wash, rinse, repeat.
> 
> Easy right? Now the bad news: Project impl sets the state to BUILDING 
> before calling Builder.build(), thus there is no clean way to move to 
> PREBUILD before we're already in the BUILDING state. See
Project.build()
> 
> for details.
> 
> Also, if we change Project.build() to call a new Builder.preBuild() 
> method before calling Builder.build(), the CCDist case/impl of 
> preBuild() really needs to find and hold an available agent AND
somehow 
> return that agent from the .preBuild() call AND now Builder.build()
has 
> to pass that agent in to the Builder.build() call... it gets messy
fast.
> 
> If we find a good design to solve the mess above, the effect on 
> non-CCDist builds would be simply that each build goes from PREBUILD
to 
> BUILDING immediately. I don't think that is a big deal. The real 
> challenge is cleanly altering the State system without introducing a
ton
> 
> of coupling, nor requiring changes to all existing Builder impls...
> 
> I'm open to ideas on better ways to handle this. Also, I didn't dig
into
> 
> how the actual build times are created (to make sure the whole 
> "PREBUILD" state idea would actually solve this). Maybe the details of

> how the build times work could shed light on another approach.
> 
> Thoughts?
> 
> Dan
> 
> 
> 

EJ Ciramella wrote:
> Uggg - that ramped up fast - I was thinking, why not have the status
> that's on the build page be written out to the buildstatus.txt file.
> Even just simply showing exactly what the build thread is doing while
> its doing it would be better than the main page of the reporting app
> saying "Building" and the project specific page saying "Waiting for
> agent of type...".
>
> Additionally, moving this info from the deeper page to the higher
level
> main page would stop people from going into each project page and
> hitting refresh and having tomcat send back what can sometimes be a
> massive build result page (of the last build).  Since this page also
> shows all the changes, sometimes it shows two or three integrations
> (with thousands of files in each changelist).
>
> Ideally, yeah, we wouldn't have the "building since" show the start of
> the build (which starts with trying to find an agent) and we'd also
not
> even put something in queue if there weren't any changes in perforce,
> but just pushing up the info so people can see (without asking releng
a
> million times) what exactly is happening.
>
> Does this sound crazy?  Thanks for replying Dan!!
>


(Reordered your reply to maintain thought train).
EJ,

Yeah, this little thing gets dicey fast. The good news is the feature
you just asked for is already in place (in the last couple releases
even). If you see the "progress message" in the individual build pages
(like: "finding agent with entries:"), then the same info is already
available on the higher level summary page: It shows as a tooltip if you
hover over the "Status (since)"

Dan

Re: [Cruisecontrol-user] Two questions

[Dan R. <dan...@gm...>]

EJ Ciramella wrote:
 > Hover vs. display - I'd lean toward display.
 >
 > Either way, I'm not getting that in 2.7.2 with firefox/ie/safari.  I'm
 > hovering over the "building since" text in the row of the build that is
 > running.
 >
 > Am I missing something?
 >


"building since"?
Mine shows "building (time)". Hover over that and you should see a tooltip.

Re: [Cruisecontrol-user] Two questions

[Dan R. <dan...@gm...>]

Dan Rollo wrote:
> EJ Ciramella wrote:
>  > Hover vs. display - I'd lean toward display.
>  >
>  > Either way, I'm not getting that in 2.7.2 with firefox/ie/safari.  I'm
>  > hovering over the "building since" text in the row of the build that is
>  > running.
>  >
>  > Am I missing something?
>  >
> 
> 
> "building since"?
> Mine shows "building (time)". Hover over that and you should see a tooltip.

If you don't see a tooltip, view the page source of the summary page. 
You should see the "title" attribute on rows with a progress message. 
For example:

               <td class="data"><a 
href="buildresults/cc-win">cc-win</a></td>
               <td class="data date status-important" title='(1:32:27 
PM) W2K-DUAL-P3 -jwebunit-tests' >building  <em>(1:18 PM)</em></td>

               <td class="data date failure">12:41 PM</td>
               <td class="data date">6/24/08</td>
               <td class="data">build.33</td>

In the above: '(1:32:27 PM) W2K-DUAL-P3 -jwebunit-tests' is the progress 
message.

If "building" projects have no such message:
1. Verify you have not set showProgress=false for the project.
2. Make sure you've updated the jsp/reporting war in your web server.

Re: [Cruisecontrol-user] Two questions

[EJ C. <ejc...@up...>]

We don't have showProgress set anywhere (not for the schedule or builder
or anything).

I don't see any of the same stuff you see (this is with 2.7.2):

<td class="data"><a href="buildresults/olmApp">olmApp</a></td>
<td class="data date status-important">building <em>(1:54 PM)</em></td>
<td class="data date failure"></td>
<td class="data date">1:20 PM</td>
<td class="data">build.30</td>

-----Original Message-----
From: Dan Rollo [mailto:dan...@gm...] 
Sent: Thursday, June 26, 2008 1:41 PM
To: EJ Ciramella
Cc: cru...@li...
Subject: Re: [Cruisecontrol-user] Two questions

Dan Rollo wrote:
> EJ Ciramella wrote:
>  > Hover vs. display - I'd lean toward display.
>  >
>  > Either way, I'm not getting that in 2.7.2 with firefox/ie/safari.
I'm
>  > hovering over the "building since" text in the row of the build
that is
>  > running.
>  >
>  > Am I missing something?
>  >
> 
> 
> "building since"?
> Mine shows "building (time)". Hover over that and you should see a
tooltip.

If you don't see a tooltip, view the page source of the summary page. 
You should see the "title" attribute on rows with a progress message. 
For example:

               <td class="data"><a 
href="buildresults/cc-win">cc-win</a></td>
               <td class="data date status-important" title='(1:32:27 
PM) W2K-DUAL-P3 -jwebunit-tests' >building  <em>(1:18 PM)</em></td>

               <td class="data date failure">12:41 PM</td>
               <td class="data date">6/24/08</td>
               <td class="data">build.33</td>

In the above: '(1:32:27 PM) W2K-DUAL-P3 -jwebunit-tests' is the progress

message.

If "building" projects have no such message:
1. Verify you have not set showProgress=false for the project.
2. Make sure you've updated the jsp/reporting war in your web server.

Re: [Cruisecontrol-user] Two questions

[Dan R. <dan...@gm...>]

How 'bout this?
 > 2. Make sure you've updated the jsp/reporting war in your web server.

EJ Ciramella wrote:
> We don't have showProgress set anywhere (not for the schedule or builder
> or anything).
> 
> I don't see any of the same stuff you see (this is with 2.7.2):
> 
> <td class="data"><a href="buildresults/olmApp">olmApp</a></td>
> <td class="data date status-important">building <em>(1:54 PM)</em></td>
> <td class="data date failure"></td>
> <td class="data date">1:20 PM</td>
> <td class="data">build.30</td>
> 
> -----Original Message-----
> From: Dan Rollo [mailto:dan...@gm...] 
> Sent: Thursday, June 26, 2008 1:41 PM
> To: EJ Ciramella
> Cc: cru...@li...
> Subject: Re: [Cruisecontrol-user] Two questions
> 
> Dan Rollo wrote:
>> EJ Ciramella wrote:
>>  > Hover vs. display - I'd lean toward display.
>>  >
>>  > Either way, I'm not getting that in 2.7.2 with firefox/ie/safari.
> I'm
>>  > hovering over the "building since" text in the row of the build
> that is
>>  > running.
>>  >
>>  > Am I missing something?
>>  >
>>
>>
>> "building since"?
>> Mine shows "building (time)". Hover over that and you should see a
> tooltip.
> 
> If you don't see a tooltip, view the page source of the summary page. 
> You should see the "title" attribute on rows with a progress message. 
> For example:
> 
>                <td class="data"><a 
> href="buildresults/cc-win">cc-win</a></td>
>                <td class="data date status-important" title='(1:32:27 
> PM) W2K-DUAL-P3 -jwebunit-tests' >building  <em>(1:18 PM)</em></td>
> 
>                <td class="data date failure">12:41 PM</td>
>                <td class="data date">6/24/08</td>
>                <td class="data">build.33</td>
> 
> In the above: '(1:32:27 PM) W2K-DUAL-P3 -jwebunit-tests' is the progress
> 
> message.
> 
> If "building" projects have no such message:
> 1. Verify you have not set showProgress=false for the project.
> 2. Make sure you've updated the jsp/reporting war in your web server.

Re: [Cruisecontrol-user] Two questions

[Michael D. <mde...@up...>]

Dan,

We deleted the webapp/cruisecontrol directory in Tomcat and redeploy the
WAR file; then restarted Tomcat.

We still don't see the 'title' attributed in the tag.
<tr class="even-row ">
	<td class="data"><a href="buildresults/olmApp">olmApp</a></td>
      <td class="data date status-important">building
<em>(3:31PM)</em></td>
	<td class="data date failure"></td>
      <td class="data date">3:22 PM</td>
      <td class="data">build.33</td>

If I look at index.jsp, I see the code that would put the attribute tag
there but for some reason it's not showing up for us.



-----Original Message-----
From: cru...@li...
[mailto:cru...@li...] On Behalf Of
Dan Rollo
Sent: Thursday, June 26, 2008 3:30 PM
To: EJ Ciramella
Cc: cru...@li...
Subject: Re: [Cruisecontrol-user] Two questions

How 'bout this?
 > 2. Make sure you've updated the jsp/reporting war in your web server.

EJ Ciramella wrote:
> We don't have showProgress set anywhere (not for the schedule or
builder
> or anything).
> 
> I don't see any of the same stuff you see (this is with 2.7.2):
> 
> <td class="data"><a href="buildresults/olmApp">olmApp</a></td>
> <td class="data date status-important">building <em>(1:54
PM)</em></td>
> <td class="data date failure"></td>
> <td class="data date">1:20 PM</td>
> <td class="data">build.30</td>
> 
> -----Original Message-----
> From: Dan Rollo [mailto:dan...@gm...] 
> Sent: Thursday, June 26, 2008 1:41 PM
> To: EJ Ciramella
> Cc: cru...@li...
> Subject: Re: [Cruisecontrol-user] Two questions
> 
> Dan Rollo wrote:
>> EJ Ciramella wrote:
>>  > Hover vs. display - I'd lean toward display.
>>  >
>>  > Either way, I'm not getting that in 2.7.2 with firefox/ie/safari.
> I'm
>>  > hovering over the "building since" text in the row of the build
> that is
>>  > running.
>>  >
>>  > Am I missing something?
>>  >
>>
>>
>> "building since"?
>> Mine shows "building (time)". Hover over that and you should see a
> tooltip.
> 
> If you don't see a tooltip, view the page source of the summary page. 
> You should see the "title" attribute on rows with a progress message. 
> For example:
> 
>                <td class="data"><a 
> href="buildresults/cc-win">cc-win</a></td>
>                <td class="data date status-important" title='(1:32:27 
> PM) W2K-DUAL-P3 -jwebunit-tests' >building  <em>(1:18 PM)</em></td>
> 
>                <td class="data date failure">12:41 PM</td>
>                <td class="data date">6/24/08</td>
>                <td class="data">build.33</td>
> 
> In the above: '(1:32:27 PM) W2K-DUAL-P3 -jwebunit-tests' is the
progress
> 
> message.
> 
> If "building" projects have no such message:
> 1. Verify you have not set showProgress=false for the project.
> 2. Make sure you've updated the jsp/reporting war in your web server.


------------------------------------------------------------------------
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Cruisecontrol-user mailing list
Cru...@li...
https://lists.sourceforge.net/lists/listinfo/cruisecontrol-user

Re: [Cruisecontrol-user] Two questions

[EJ C. <ejc...@up...>]

I think we had cruft lying around in our tomcat's work directory.

Cleaning that up seems to have made a difference.

I'd still bet that people will continue to ask, why not just have the
status reflect what the hover says instead of just saying, "building
(<time>)"?

I guess we could just set our version to do that by default.

/shrug

-----Original Message-----
From: Michael Delaney 
Sent: Thursday, June 26, 2008 3:50 PM
To: 'cru...@li...'; EJ Ciramella
Subject: RE: [Cruisecontrol-user] Two questions

Dan,

We deleted the webapp/cruisecontrol directory in Tomcat and redeploy the
WAR file; then restarted Tomcat.

We still don't see the 'title' attributed in the tag.
<tr class="even-row ">
	<td class="data"><a href="buildresults/olmApp">olmApp</a></td>
      <td class="data date status-important">building
<em>(3:31PM)</em></td>
	<td class="data date failure"></td>
      <td class="data date">3:22 PM</td>
      <td class="data">build.33</td>

If I look at index.jsp, I see the code that would put the attribute tag
there but for some reason it's not showing up for us.



-----Original Message-----
From: cru...@li...
[mailto:cru...@li...] On Behalf Of
Dan Rollo
Sent: Thursday, June 26, 2008 3:30 PM
To: EJ Ciramella
Cc: cru...@li...
Subject: Re: [Cruisecontrol-user] Two questions

How 'bout this?
 > 2. Make sure you've updated the jsp/reporting war in your web server.

EJ Ciramella wrote:
> We don't have showProgress set anywhere (not for the schedule or
builder
> or anything).
> 
> I don't see any of the same stuff you see (this is with 2.7.2):
> 
> <td class="data"><a href="buildresults/olmApp">olmApp</a></td>
> <td class="data date status-important">building <em>(1:54
PM)</em></td>
> <td class="data date failure"></td>
> <td class="data date">1:20 PM</td>
> <td class="data">build.30</td>
> 
> -----Original Message-----
> From: Dan Rollo [mailto:dan...@gm...] 
> Sent: Thursday, June 26, 2008 1:41 PM
> To: EJ Ciramella
> Cc: cru...@li...
> Subject: Re: [Cruisecontrol-user] Two questions
> 
> Dan Rollo wrote:
>> EJ Ciramella wrote:
>>  > Hover vs. display - I'd lean toward display.
>>  >
>>  > Either way, I'm not getting that in 2.7.2 with firefox/ie/safari.
> I'm
>>  > hovering over the "building since" text in the row of the build
> that is
>>  > running.
>>  >
>>  > Am I missing something?
>>  >
>>
>>
>> "building since"?
>> Mine shows "building (time)". Hover over that and you should see a
> tooltip.
> 
> If you don't see a tooltip, view the page source of the summary page. 
> You should see the "title" attribute on rows with a progress message. 
> For example:
> 
>                <td class="data"><a 
> href="buildresults/cc-win">cc-win</a></td>
>                <td class="data date status-important" title='(1:32:27 
> PM) W2K-DUAL-P3 -jwebunit-tests' >building  <em>(1:18 PM)</em></td>
> 
>                <td class="data date failure">12:41 PM</td>
>                <td class="data date">6/24/08</td>
>                <td class="data">build.33</td>
> 
> In the above: '(1:32:27 PM) W2K-DUAL-P3 -jwebunit-tests' is the
progress
> 
> message.
> 
> If "building" projects have no such message:
> 1. Verify you have not set showProgress=false for the project.
> 2. Make sure you've updated the jsp/reporting war in your web server.


------------------------------------------------------------------------
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Cruisecontrol-user mailing list
Cru...@li...
https://lists.sourceforge.net/lists/listinfo/cruisecontrol-user