immediate build or "overwrite quiet period"

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

immediate build or "overwrite quiet period"

Johannes Eickhold
Hi,

it would be nice if a project waiting in the Build Queue for its quite
period to expire could be forced to build immediately. Maybe a new
button next to the cancel button of the build queue entry could be
introduced.

What do you think about this?

This feature would be very useful for those who incorporated hudson in
their "look on build results"-"fix a failed test"-"commit"-"wait for new
build"-"look on test results" cycle. The step "wait for new build" could
be shortened this way. I for example use a quiet period of 300 seconds
to aggregate commits because I often don't commit all my changes in one
commit at once.

Greets,
  Johannes.

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: immediate build or "overwrite quiet period"

Kohsuke Kawaguchi
Administrator
Johannes Eickhold wrote:
> Hi,
>
> it would be nice if a project waiting in the Build Queue for its quite
> period to expire could be forced to build immediately. Maybe a new
> button next to the cancel button of the build queue entry could be
> introduced.
>
> What do you think about this?

See #356 for a related build.

> This feature would be very useful for those who incorporated hudson in
> their "look on build results"-"fix a failed test"-"commit"-"wait for new
> build"-"look on test results" cycle. The step "wait for new build" could
> be shortened this way. I for example use a quiet period of 300 seconds
> to aggregate commits because I often don't commit all my changes in one
> commit at once.

What I should have really done is, instead of making the quiet period a
project property like it is today, I should have made it a property of
the SCM trigger (and allow the query parameter in the build link like
http://myserver/hudson/job/abc/build?quietPeriod=300 for wget-based
triggering.)

Those are really the only two places that need a quiet period.

However, making this change means breaking a compatibility, which makes
me bit nervous.

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

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

Re: immediate build or "overwrite quiet period"

Johannes Eickhold
On Sun, 2007-04-29 at 17:02 -0700, Kohsuke Kawaguchi wrote:

> Johannes Eickhold wrote:
> > This feature would be very useful for those who incorporated hudson in
> > their "look on build results"-"fix a failed test"-"commit"-"wait for new
> > build"-"look on test results" cycle. The step "wait for new build" could
> > be shortened this way. I for example use a quiet period of 300 seconds
> > to aggregate commits because I often don't commit all my changes in one
> > commit at once.
>
> What I should have really done is, instead of making the quiet period a
> project property like it is today, I should have made it a property of
> the SCM trigger (and allow the query parameter in the build link like
> http://myserver/hudson/job/abc/build?quietPeriod=300 for wget-based
> triggering.)
>
> Those are really the only two places that need a quiet period.
>
> However, making this change means breaking a compatibility, which makes
> me bit nervous.
What about a soft transition? Like:

1. introduce quietPeriod query parameter
2. mark project property "quiet period" as deprecated (i.e. "will be
removed")
3. change "build now" to ignore the quiet period
4. wait a few releases
5. remove project property "quiet period"

Greets,
  Johannes.

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: immediate build or "overwrite quiet period"

Johannes Eickhold
In reply to this post by Kohsuke Kawaguchi
On Sun, 2007-04-29 at 17:02 -0700, Kohsuke Kawaguchi wrote:

> Johannes Eickhold wrote:
> > This feature would be very useful for those who incorporated hudson in
> > their "look on build results"-"fix a failed test"-"commit"-"wait for new
> > build"-"look on test results" cycle. The step "wait for new build" could
> > be shortened this way. I for example use a quiet period of 300 seconds
> > to aggregate commits because I often don't commit all my changes in one
> > commit at once.
>
> What I should have really done is, instead of making the quiet period a
> project property like it is today, I should have made it a property of
> the SCM trigger (and allow the query parameter in the build link like
> http://myserver/hudson/job/abc/build?quietPeriod=300 for wget-based
> triggering.)
Nevertheless, forcing a build with unexpired quiet period out of the
queue would still be a missing feature, right?

Greets,
  Johannes.

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: immediate build or "overwrite quiet period"

Kohsuke Kawaguchi
Administrator
Johannes Eickhold wrote:
> Nevertheless, forcing a build with unexpired quiet period out of the
> queue would still be a missing feature, right?

Not really. In the proposed scheme where the quiet period only applies
to wget and SCM trigger, Clicking "Build now" would force the build to
start immediately.

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

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

Re: immediate build or "overwrite quiet period"

Kohsuke Kawaguchi
Administrator
In reply to this post by Johannes Eickhold
Johannes Eickhold wrote:
>> However, making this change means breaking a compatibility, which makes
>> me bit nervous.
>
> What about a soft transition? Like:
>
> 1. introduce quietPeriod query parameter
> 2. mark project property "quiet period" as deprecated (i.e. "will be
> removed")
> 3. change "build now" to ignore the quiet period

This is a breaking change, as wget scripts out there emulates clicking
this link.

> 4. wait a few releases
> 5. remove project property "quiet period"

... and I found that many people don't upgrade Hudson unless they have a
convincing new feature to justify the upgrade effort/risk, which could
be quite a long time.


But you are probably right that there should be a way to make this
transition less painful. Breaking this compatibility is not all that
problematic either, I think.



--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

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

Re: immediate build or "overwrite quiet period"

Johannes Eickhold
In reply to this post by Kohsuke Kawaguchi
On Sun, 2007-04-29 at 17:43 -0700, Kohsuke Kawaguchi wrote:
> Johannes Eickhold wrote:
> > Nevertheless, forcing a build with unexpired quiet period out of the
> > queue would still be a missing feature, right?
>
> Not really. In the proposed scheme where the quiet period only applies
> to wget and SCM trigger, Clicking "Build now" would force the build to
> start immediately.

Clicking "Build now" would start the scheduled build from the queue to
start immediatly? To make it clear: "Build now" wouldn't ever start
another build of Project A, if project A already has a build in the
queue?

Greets,
  Johannes.

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: immediate build or "overwrite quiet period"

Kohsuke Kawaguchi
Administrator
2007/4/30, Johannes Eickhold <[hidden email]>:
> Clicking "Build now" would start the scheduled build from the queue to
> start immediatly? To make it clear: "Build now" wouldn't ever start
> another build of Project A, if project A already has a build in the
> queue?

Yeah, if the queit period of an item in the queue is determined by the
smallest value, then submitting an item with quiet period 0 would have
an effect of immediately trying to execute the item in queue (whether
the build actually runs immediately is subject to other conditions,
like node availability etc.)

--
Kohsuke Kawaguchi

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