Cancelling builds

[Kenney Westerhof <ke...@apache.org>]

Hi Team,

Yesterday I've committed some code to enable cancelling builds:

* Schedules have a setting that indicates the maximum job execution time,
  where job means BuildProjectTask; 0 means indefinitely, the default being 1 hour.

* You can cancel a running build. 

I'm not sure where to put the cancel build button, so right now I've added a '(cancel)' link
to the StateCell that's displayed in the projectGroupSummaryAction page (and probably other places).

Some questions/remarks:

- What's the best place to place the cancel build button? 
  
  Perhaps just list the job on the summary page as 'current job'
  (in the future: current jobs) and add a cancel button there.

- The build ID of the cancelled task will either be 0 or max(build id),
  depending on when it's cancelled. The project _is_ set in error state
  so it finishes normally. This gives me the idea that the build number issue
  already was there; this needs to be fixed (I'm looking into it).

- The results page is broken - some jdo detached error with scmResults. I can't figure out
  why it doesn't work.

- We might want to set a timeout on individual actions instead of the entire job (1.2?)

- An issue Emmanuel has pointed out to me is that cancelling builds on windows doesn't work
  well. I've dug into the sun site and found several others with the same problem.

  The issue is that on windows, if you execute a batchfile (Runtime.exec) and you cancel that,
  any process started in the batchfile isn't killed. This is due to windows process management.
    
  Just a question: why not call m1/m2/java from a new classloader/thread within continuum itself? Saves some shell magick,
  and it's more easily killed (using the concurrent package). Or call java directly - also no problem with killing that
  and any child processes.

-- Kenney

Re: Cancelling builds

[Emmanuel Venisse <em...@venisse.net>]

Kenney Westerhof a écrit :
>
> Hi Team,
>
> Yesterday I've committed some code to enable cancelling builds:
>
> * Schedules have a setting that indicates the maximum job execution time,
>  where job means BuildProjectTask; 0 means indefinitely, the default
> being 1 hour.
>
> * You can cancel a running build.
> I'm not sure where to put the cancel build button, so right now I've
> added a '(cancel)' link
> to the StateCell that's displayed in the projectGroupSummaryAction page
> (and probably other places).
>
> Some questions/remarks:
>
> - What's the best place to place the cancel build button?
>  Perhaps just list the job on the summary page as 'current job'
>  (in the future: current jobs) and add a cancel button there.
>
> - The build ID of the cancelled task will either be 0 or max(build id),
>  depending on when it's cancelled. The project _is_ set in error state
>  so it finishes normally. This gives me the idea that the build number
> issue
>  already was there; this needs to be fixed (I'm looking into it).
>
> - The results page is broken - some jdo detached error with scmResults.
> I can't figure out
>  why it doesn't work.
>
> - We might want to set a timeout on individual actions instead of the
> entire job (1.2?)
>
> - An issue Emmanuel has pointed out to me is that cancelling builds on
> windows doesn't work
>  well. I've dug into the sun site and found several others with the same
> problem.
>
>  The issue is that on windows, if you execute a batchfile (Runtime.exec)
> and you cancel that,
>  any process started in the batchfile isn't killed. This is due to
> windows process management.

I don't know if when you use prcview, it kill subprocess. If not, it's possible to do it because
prcview know the hierarchy between processes and we can delete them one by one.

'pv -t' print the tree of all processes
'pv -o"%i %r %f" print process id, parent id, full command line


>     Just a question: why not call m1/m2/java from a new
> classloader/thread within continuum itself? Saves some shell magick,
>  and it's more easily killed (using the concurrent package). Or call
> java directly - also no problem with killing that
>  and any child processes.

I don't think it would be a good idea to launch maven/ant/java in a new classloader/thread because
the memory used by continuum won't be the same, users will need to increase the memory used by
continuum for all projects that required lot of memory for a build. The second point in that some
users don't use the standard ant/maven scripts but a specific for some reason, so I don't think they
like to skip the batch phase used in ant/maven.

Emmanuel

Re: Cancelling builds

[Brett Porter <br...@apache.org>]

On 14/09/2006, at 6:29 PM, Carlos Sanchez wrote:

>> - The results page is broken - some jdo detached error with  
>> scmResults. I can't figure out
>>   why it doesn't work.
>
> This and a lot more bugs have been fixed in the acegi branch. I'll
> merge them back when I have some time, but if you need something look
> there first.

Carlos, can you identify which fixes they are and look after getting  
them back onto trunk?

- Brett

Re: Cancelling builds

[Carlos Sanchez <ca...@apache.org>]

On 9/14/06, Kenney Westerhof <ke...@apache.org> wrote:
>
> Hi Team,
>
> Yesterday I've committed some code to enable cancelling builds:
>
> * Schedules have a setting that indicates the maximum job execution time,
>   where job means BuildProjectTask; 0 means indefinitely, the default being 1 hour.
>
> * You can cancel a running build.
>
> I'm not sure where to put the cancel build button, so right now I've added a '(cancel)' link
> to the StateCell that's displayed in the projectGroupSummaryAction page (and probably other places).
>
> Some questions/remarks:
>
> - What's the best place to place the cancel build button?
>
>   Perhaps just list the job on the summary page as 'current job'
>   (in the future: current jobs) and add a cancel button there.
>
> - The build ID of the cancelled task will either be 0 or max(build id),
>   depending on when it's cancelled. The project _is_ set in error state
>   so it finishes normally. This gives me the idea that the build number issue
>   already was there; this needs to be fixed (I'm looking into it).
>
> - The results page is broken - some jdo detached error with scmResults. I can't figure out
>   why it doesn't work.

This and a lot more bugs have been fixed in the acegi branch. I'll
merge them back when I have some time, but if you need something look
there first.

>
> - We might want to set a timeout on individual actions instead of the entire job (1.2?)
>
> - An issue Emmanuel has pointed out to me is that cancelling builds on windows doesn't work
>   well. I've dug into the sun site and found several others with the same problem.
>
>   The issue is that on windows, if you execute a batchfile (Runtime.exec) and you cancel that,
>   any process started in the batchfile isn't killed. This is due to windows process management.
>
>   Just a question: why not call m1/m2/java from a new classloader/thread within continuum itself? Saves some shell magick,
>   and it's more easily killed (using the concurrent package). Or call java directly - also no problem with killing that
>   and any child processes.
>
> -- Kenney
>


-- 
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

Re: Cancelling builds

[Kenney Westerhof <ke...@apache.org>]

Brett Porter wrote:
> 
> On 14/09/2006, at 6:09 PM, Kenney Westerhof wrote:
> 
>>
>> Hi Team,
>>
>> Yesterday I've committed some code to enable cancelling builds:
> 
> Great!
> 
>> - What's the best place to place the cancel build button?   Perhaps 
>> just list the job on the summary page as 'current job'
>>  (in the future: current jobs) and add a cancel button there.
> 
> How about replacing the "build now" button (which is disabled when a 
> build is in progress) with a "cancel build" button? replace the green 
> "play" symbol with the delete "x".

Sounds good! I've Gimped a small icon but someone with real graphics skills
might want to redo it.

> 
>>
>> - The build ID of the cancelled task will either be 0 or max(build id),
>>  depending on when it's cancelled. The project _is_ set in error state
>>  so it finishes normally. This gives me the idea that the build number 
>> issue
>>  already was there; this needs to be fixed (I'm looking into it).
> 
> Is setting it to error state appropriate? That makes sense if it times 
> out, but maybe if it is cancelled it should be set back to the last 
> state? Or set to a new cancelled state?

A new cancelled state sounds good to me (but it'll be a lot of work since we're not
using enums and a lot of code uses integer constants ;)

Right now there's no way for the task to see if it was cancelled manually or because
it was killed by the executor because it has timed out, so I'll go with the new cancelled state.
I'll use the warning triangle for now.

> 
>>
>> - We might want to set a timeout on individual actions instead of the 
>> entire job (1.2?)
> 
> Sorry, what do you mean by "individual actions"? 

I'm sorry, I meant actions like 'update-working-directory-from-scm' etc. 

>> - An issue Emmanuel has pointed out to me is that cancelling builds on 
>> windows doesn't work
>>  well. I've dug into the sun site and found several others with the 
>> same problem.
> 
> This is ok. We should look into the prcview thing, but I don't think its 
> a high priority. We can list as a known issue.
> 

Oh okay then :)

>>     Just a question: why not call m1/m2/java from a new 
>> classloader/thread within continuum itself? Saves some shell magick,
>>  and it's more easily killed (using the concurrent package). Or call 
>> java directly - also no problem with killing that
>>  and any child processes.
> 
> This might be a useful feature at some point, but can never be the only 
> way. People will want to use various versions of Maven and JDK, not just 
> the ones Continuum has.

True, but once the maven location has been discovered it's quite easy to call Main
using the classes found in the maven installation directory.

Especially for Maven 2 it might make things feel more integrated - continuum could attach 
listeners and doesn't have to work with passing information through files. Although this
also only works for specific maven versions.

-- Kenney

Re: Cancelling builds

[Brett Porter <br...@apache.org>]

On 14/09/2006, at 6:09 PM, Kenney Westerhof wrote:

>
> Hi Team,
>
> Yesterday I've committed some code to enable cancelling builds:

Great!

> - What's the best place to place the cancel build button?   Perhaps  
> just list the job on the summary page as 'current job'
>  (in the future: current jobs) and add a cancel button there.

How about replacing the "build now" button (which is disabled when a  
build is in progress) with a "cancel build" button? replace the green  
"play" symbol with the delete "x".

>
> - The build ID of the cancelled task will either be 0 or max(build  
> id),
>  depending on when it's cancelled. The project _is_ set in error state
>  so it finishes normally. This gives me the idea that the build  
> number issue
>  already was there; this needs to be fixed (I'm looking into it).

Is setting it to error state appropriate? That makes sense if it  
times out, but maybe if it is cancelled it should be set back to the  
last state? Or set to a new cancelled state?

>
> - We might want to set a timeout on individual actions instead of  
> the entire job (1.2?)

Sorry, what do you mean by "individual actions"?

>
> - An issue Emmanuel has pointed out to me is that cancelling builds  
> on windows doesn't work
>  well. I've dug into the sun site and found several others with the  
> same problem.

This is ok. We should look into the prcview thing, but I don't think  
its a high priority. We can list as a known issue.

>
>  The issue is that on windows, if you execute a batchfile  
> (Runtime.exec) and you cancel that,
>  any process started in the batchfile isn't killed. This is due to  
> windows process management.
>     Just a question: why not call m1/m2/java from a new classloader/ 
> thread within continuum itself? Saves some shell magick,
>  and it's more easily killed (using the concurrent package). Or  
> call java directly - also no problem with killing that
>  and any child processes.

This might be a useful feature at some point, but can never be the  
only way. People will want to use various versions of Maven and JDK,  
not just the ones Continuum has.

Cheers,
Brett

>
> -- Kenney