tbcleanup feature requests :)

[Joe Marcus Clarke]

On Thu, 2008-07-10 at 01:52 +0300, Ion-Mihai Tetcu wrote:
> On Wed, 09 Jul 2008 17:34:42 -0400
> Joe Marcus Clarke <marcus at marcuscom.com> wrote:
> 
> > On Wed, 2008-07-09 at 10:58 +0300, Ion-Mihai Tetcu wrote:
> > 
> > > - have build_ports.Last_Fail_Reason exported to postPortBuild Hook
> > > - I need it for setting a relevant subject to the BotmMail; right
> > > now $STATUS only gives me SUCCESS, FAIL and DUDS.
> > 
> > I just did this in HEAD.
> 
> Any chance of MFC?

No.  I'm not doing anymore MFHs since I want to get a 3.0 release out.
But it would be easy to port to 2.x.

> 
> > > - have a little better failure patterns, especially for ports that
> > > fail because they need kernel sources. I'm willing to go in in all
> > > ports and change the failure message to be the same (like 'This
> > > port requires the kernel source be available') and to fail in the
> > > same make target if this would help (maybe this could even be
> > > implemented via a KNOB in b.p.m).
> > 
> > I need to re-sync the failure patterns with pointyhat.  
> 
> :-) again, MFC? I'm reluctant to use HEAD for QA Tindy esp. since I
> plan to enable completely automatic BotMails.
> 
> BTW, any ETA for the next release (from HEAD)?

I want to make this happen, but there are a few things that need to
happen first:

* Documentation sweep to make sure all docs are in line with how things
work in 3.0.

* Some kind of automated upgrade (like we have in 2.x) or documentation
on how to do the upgrade.

* Beta/RC period to make sure there are no regressions.

Once the first two items happen, the third item can begin.  Clearly,
documenting the upgrade steps would be easier than trying to do an
automated tool.  Unless anyone wants to step up, and do the upgrade
work, I'm just going to go the documentation route.

> > > I'm a little bit at lost how to implement differentiating between
> > > "regular" and commit triggered builds/errors. The thing is I have to
> > > send a BotMail each time a port is touched by a commit and it fails,
> > > but not for the ports that fail because of my regular builds or
> > > because they are dependencies of an other port (else some people
> > > would receive a few dozens emails per day about the same port).
> > > Right now I queue regular port builds with priority 9 and
> > > commit-triggered builds with priority 5. Maybe it would be possible
> > > to export this to the postPortBuild hook? Any suggestion is
> > > welcomed.
> > 
> > I suppose it would be possible to export the CLI arguments passed to
> > tinderbuild on the command line to related Hooks.  Would this be
> > acceptable?
> 
> I guess so. I'm querying mysql directly now (which happens to be faster
> that getting the results from ./tc) so this is not something I really
> need.

What are you querying in the database?  Using tc shouldn't be that much
slower.

> 
> BTW, ports_build_queue.Enqueue_Date is set only if the port was queued
> via the web interface and not via CLI. Is this by design?

No idea.  I have nothing to do with the queuing stuff as I've never used
it.  It sounds like a bug to me, though.

> 
> 
> Question: Is ports_build_queue.Build_Ports_Queue_Id being reset (since
> it's auto_increment) in any case (like when running tbcleanup)? I need
> to keep some other info related to each queue entry in an other table
> so I need to know if I can depend on it or not.

I know tbcleanup is not touching it.  As far as I can tell nothing
touches this field directly (though queued ports will be deleted).

Joe

-- 
PGP Key : http://www.marcuscom.com/pgp.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <http://marcuscom.com/pipermail/tinderbox-list/attachments/20080709/6f97a23b/attachment.bin>