[Buildbot-devel] [Buildbot] #2703: handle step interruption properly

[Pierre Tardy]

Thanks I haven't managed to change the description. Do I need special
privilege?
Le 23 févr. 2014 15:17, "Buildbot trac" <trac at buildbot.net> a écrit :

> #2703: handle step interruption properly
> -------------------+--------------------
> Reporter:  tardyp  |       Owner:
>     Type:  task    |      Status:  new
> Priority:  major   |   Milestone:  0.9.0
>  Version:  master  |  Resolution:
> Keywords:          |
> -------------------+--------------------
> Description changed by dustin:
>
> Old description:
>
> > There are some subtleties to handle step interrupts.
> >
> > For shellcommands this works, but for master steps its more complex.
> > especially trigger would need special attention.
> >
> > <tardyp> djmitche, in the case of a new style step, how are you supposed
> > to interrupt a step?
> > »» tardyp converting Trigger to new style..
> > <+djmitche> tardyp: has that changed?
> > <tardyp> well if I run interrupt(), we are in the middle of run(), which
> > would be yielding someting
> > <tardyp> old style step would just call self.finished() so can skip
> > waiting
> > <+djmitche> interrupt will also interrupt a running command
> > <+djmitche> so this is only a problem when run() isn't executing a
> > command
> > <tardyp> I realize that trigger's interrupt is badly written
> > <tardyp> it should cancel the requests
> > <tardyp> and stop the builds
> > <+djmitche> yes
> > <+djmitche> there should be some instructions for step authors who are
> > not just executing commands to poll self.stopped or something like that
> > <tardyp> the first is easy, end the second need the stop rpc
> > <+djmitche> also, initiating a new command after an interrupt should
> > immediately fail
> > <+djmitche> I don't think it necessarily should stop the triggered builds
> > <tardyp> well, we have hacks to do so, as my user were requesting this
> > loud
> > <+djmitche> what if those requests got merged?
> > <tardyp> it make sense to release the buildfarm, when like use a single
> > build can trigger douzens of parralel builds
> > <tardyp> the algo is to claim_cancel the buildrequests first
> > <tardyp> then if the buildrequests are claimed, get to the build status
> > and stop it
> > <+djmitche> I suppose if we're collapsing requests instead, then if the
> > request was collapsed, you just don't cancel a build
> > <tardyp> so I believe this works with the collapsing
> > <+djmitche> yeah
> > <tardyp> if it is callapsed then its claimed
> > <+djmitche> as long as it's via the data API I think that's OK :)
>
> New description:
>
>  There are some subtleties to handle step interrupts.
>
>  For shellcommands this works, but for master steps its more complex.
>  especially trigger would need special attention.
>
>  {{{
>  <tardyp> djmitche, in the case of a new style step, how are you supposed
>  to interrupt a step?
>  »» tardyp converting Trigger to new style..
>  <+djmitche> tardyp: has that changed?
>  <tardyp> well if I run interrupt(), we are in the middle of run(), which
>  would be yielding someting
>  <tardyp> old style step would just call self.finished() so can skip
>  waiting
>  <+djmitche> interrupt will also interrupt a running command
>  <+djmitche> so this is only a problem when run() isn't executing a command
>  <tardyp> I realize that trigger's interrupt is badly written
>  <tardyp> it should cancel the requests
>  <tardyp> and stop the builds
>  <+djmitche> yes
>  <+djmitche> there should be some instructions for step authors who are not
>  just executing commands to poll self.stopped or something like that
>  <tardyp> the first is easy, end the second need the stop rpc
>  <+djmitche> also, initiating a new command after an interrupt should
>  immediately fail
>  <+djmitche> I don't think it necessarily should stop the triggered builds
>  <tardyp> well, we have hacks to do so, as my user were requesting this
>  loud
>  <+djmitche> what if those requests got merged?
>  <tardyp> it make sense to release the buildfarm, when like use a single
>  build can trigger douzens of parralel builds
>  <tardyp> the algo is to claim_cancel the buildrequests first
>  <tardyp> then if the buildrequests are claimed, get to the build status
>  and stop it
>  <+djmitche> I suppose if we're collapsing requests instead, then if the
>  request was collapsed, you just don't cancel a build
>  <tardyp> so I believe this works with the collapsing
>  <+djmitche> yeah
>  <tardyp> if it is callapsed then its claimed
>  <+djmitche> as long as it's via the data API I think that's OK :)
>  }}}
>
> --
>
> --
> Ticket URL: <http://trac.buildbot.net/ticket/2703#comment:1>
> Buildbot <http://buildbot.net/>
> Buildbot: build/test automation
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buildbot.net/pipermail/devel/attachments/20140223/f22de3d5/attachment.html>