Multiple jobs per project ?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Multiple jobs per project ?

Hugo Palma-4
I was wondering how you guys solve the problem of having normal builds
during the day that usually poll changes from the VCS and nightly builds
that are run every night at a given date and that usually have much more
processor intensive and take more time to run.

The only way i can see this configured in Hudson is to have to configure
to different jobs for the same project replicating it's configuration
only changing the schedule and the execution steps.

Is this how everyone is doing it ?

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Multiple jobs per project ?

oehl

Hi,



what do you call normal build? one that builds your product and runs unit

tests?



Fred



On Fri, 14 Dec 2007 18:34:57 +0000, Hugo Palma <[hidden email]>

wrote:

> I was wondering how you guys solve the problem of having normal builds

> during the day that usually poll changes from the VCS and nightly builds

> that are run every night at a given date and that usually have much more

> processor intensive and take more time to run.

>

> The only way i can see this configured in Hudson is to have to configure

> to different jobs for the same project replicating it's configuration

> only changing the schedule and the execution steps.

>

> Is this how everyone is doing it ?

>

> ---------------------------------------------------------------------

> To unsubscribe, e-mail: [hidden email]

> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Multiple jobs per project ?

Hugo Palma-4
yep, that's my definition of a normal build :o)

[hidden email] wrote:
Hi,



what do you call normal build? one that builds your product and runs unit

tests?



Fred



On Fri, 14 Dec 2007 18:34:57 +0000, Hugo Palma [hidden email]

wrote:

  
I was wondering how you guys solve the problem of having normal builds
    

  
during the day that usually poll changes from the VCS and nightly builds
    

  
that are run every night at a given date and that usually have much more
    

  
processor intensive and take more time to run.
    

  

  
The only way i can see this configured in Hudson is to have to configure
    

  
to different jobs for the same project replicating it's configuration
    

  
only changing the schedule and the execution steps.
    

  

  
Is this how everyone is doing it ?
    

  

  
---------------------------------------------------------------------
    

  
To unsubscribe, e-mail: [hidden email]
    

  
For additional commands, e-mail: [hidden email]
    

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


  
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Multiple jobs per project ?

Kohsuke Kawaguchi
Administrator
In reply to this post by Hugo Palma-4
Yeah, it's a bit of issue.

The way I see it is, the real question here is "I want fast feedback
but I also got long intensive computation --- what to do?"

Some suggests that we should allow different builds to do different
things, but I'm bit sceptical about this. For one thing it's bit
tricky when something don't always run (for example the "last test
result" wouldn't be "test result of the last build" any more.)

My current thinking is to fix this along the line of issue #682
<https://hudson.dev.java.net/issues/show_bug.cgi?id=682> , so that you
can set up the build part and the test part in two different but
inter-related jobs. In this way you can get the stuff built very
quickly, but you also get continuous feedback for your test part as
well.

Today I tend to set things up in a similar two-job style, where the
test job grabs the latest bits built by the earlier job. This has
similar performance characteristics as the proposal in #682, except
that the build script needs to be tweaked a little.


2007/12/14, Hugo Palma <[hidden email]>:

> I was wondering how you guys solve the problem of having normal builds
> during the day that usually poll changes from the VCS and nightly builds
> that are run every night at a given date and that usually have much more
> processor intensive and take more time to run.
>
> The only way i can see this configured in Hudson is to have to configure
> to different jobs for the same project replicating it's configuration
> only changing the schedule and the execution steps.
>
> Is this how everyone is doing it ?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Kohsuke Kawaguchi

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Multiple jobs per project ?

Hugo Palma-4
I agree with you that allowing different build to do different things could make the overall behaviour a little confusing.
The inter-related jobs idea sound good, although it doesn't seem that #682 is exactly covering that. Is there an issue for this ?


Kohsuke Kawaguchi wrote:
Yeah, it's a bit of issue.

The way I see it is, the real question here is "I want fast feedback
but I also got long intensive computation --- what to do?"

Some suggests that we should allow different builds to do different
things, but I'm bit sceptical about this. For one thing it's bit
tricky when something don't always run (for example the "last test
result" wouldn't be "test result of the last build" any more.)

My current thinking is to fix this along the line of issue #682
<https://hudson.dev.java.net/issues/show_bug.cgi?id=682> , so that you
can set up the build part and the test part in two different but
inter-related jobs. In this way you can get the stuff built very
quickly, but you also get continuous feedback for your test part as
well.

Today I tend to set things up in a similar two-job style, where the
test job grabs the latest bits built by the earlier job. This has
similar performance characteristics as the proposal in #682, except
that the build script needs to be tweaked a little.


2007/12/14, Hugo Palma [hidden email]:
  
I was wondering how you guys solve the problem of having normal builds
during the day that usually poll changes from the VCS and nightly builds
that are run every night at a given date and that usually have much more
processor intensive and take more time to run.

The only way i can see this configured in Hudson is to have to configure
to different jobs for the same project replicating it's configuration
only changing the schedule and the execution steps.

Is this how everyone is doing it ?

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


    


  
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Multiple jobs per project ?

Kohsuke Kawaguchi
Administrator
Hugo Palma wrote:
> I agree with you that allowing different build to do different things
> could make the overall behaviour a little confusing.
> The inter-related jobs idea sound good, although it doesn't seem that
> #682 is exactly covering that. Is there an issue for this ?

I guess the way I see it is this belt-conveyor style workspace sharing
is a generalization of the original problem described in #682 as well as
yours.

I think I'd encourage you to just add yourself to CC of this. Given the
frequency of people pinging about this, I think I really need to work on
it...

>
>
> Kohsuke Kawaguchi wrote:
>> Yeah, it's a bit of issue.
>>
>> The way I see it is, the real question here is "I want fast feedback
>> but I also got long intensive computation --- what to do?"
>>
>> Some suggests that we should allow different builds to do different
>> things, but I'm bit sceptical about this. For one thing it's bit
>> tricky when something don't always run (for example the "last test
>> result" wouldn't be "test result of the last build" any more.)
>>
>> My current thinking is to fix this along the line of issue #682
>> <https://hudson.dev.java.net/issues/show_bug.cgi?id=682> , so that you
>> can set up the build part and the test part in two different but
>> inter-related jobs. In this way you can get the stuff built very
>> quickly, but you also get continuous feedback for your test part as
>> well.
>>
>> Today I tend to set things up in a similar two-job style, where the
>> test job grabs the latest bits built by the earlier job. This has
>> similar performance characteristics as the proposal in #682, except
>> that the build script needs to be tweaked a little.
>>
>>
>> 2007/12/14, Hugo Palma <[hidden email]>:
>>  
>>> I was wondering how you guys solve the problem of having normal builds
>>> during the day that usually poll changes from the VCS and nightly builds
>>> that are run every night at a given date and that usually have much more
>>> processor intensive and take more time to run.
>>>
>>> The only way i can see this configured in Hudson is to have to configure
>>> to different jobs for the same project replicating it's configuration
>>> only changing the schedule and the execution steps.
>>>
>>> Is this how everyone is doing it ?
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>>    
>>
>>
>>  
>

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Multiple jobs per project ?

Hugo Palma-4
Ok, thanks.

About the CC, i would if i could. I'm still to figure out why i can't
either comment or add myself to CC in dev.java.net issues. It seems that
the only things i can do is create issues and vote for issues.

Kohsuke Kawaguchi wrote:

> Hugo Palma wrote:
>> I agree with you that allowing different build to do different things
>> could make the overall behaviour a little confusing.
>> The inter-related jobs idea sound good, although it doesn't seem that
>> #682 is exactly covering that. Is there an issue for this ?
>
> I guess the way I see it is this belt-conveyor style workspace sharing
> is a generalization of the original problem described in #682 as well
> as yours.
>
> I think I'd encourage you to just add yourself to CC of this. Given
> the frequency of people pinging about this, I think I really need to
> work on it...
>
>>
>>
>> Kohsuke Kawaguchi wrote:
>>> Yeah, it's a bit of issue.
>>>
>>> The way I see it is, the real question here is "I want fast feedback
>>> but I also got long intensive computation --- what to do?"
>>>
>>> Some suggests that we should allow different builds to do different
>>> things, but I'm bit sceptical about this. For one thing it's bit
>>> tricky when something don't always run (for example the "last test
>>> result" wouldn't be "test result of the last build" any more.)
>>>
>>> My current thinking is to fix this along the line of issue #682
>>> <https://hudson.dev.java.net/issues/show_bug.cgi?id=682> , so that you
>>> can set up the build part and the test part in two different but
>>> inter-related jobs. In this way you can get the stuff built very
>>> quickly, but you also get continuous feedback for your test part as
>>> well.
>>>
>>> Today I tend to set things up in a similar two-job style, where the
>>> test job grabs the latest bits built by the earlier job. This has
>>> similar performance characteristics as the proposal in #682, except
>>> that the build script needs to be tweaked a little.
>>>
>>>
>>> 2007/12/14, Hugo Palma <[hidden email]>:
>>>  
>>>> I was wondering how you guys solve the problem of having normal builds
>>>> during the day that usually poll changes from the VCS and nightly
>>>> builds
>>>> that are run every night at a given date and that usually have much
>>>> more
>>>> processor intensive and take more time to run.
>>>>
>>>> The only way i can see this configured in Hudson is to have to
>>>> configure
>>>> to different jobs for the same project replicating it's configuration
>>>> only changing the schedule and the execution steps.
>>>>
>>>> Is this how everyone is doing it ?
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>>    
>>>
>>>
>>>  
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Loading...