buildd maintainers need to be informed of build failures

[Adam Conrad]

I need to be able to get build logs from any unsuccessful builds mailed to me as the builds fail, so I don't spend my whole day refreshing a web page to see what's recently failed.

Whether this is in the form of an entire build log mailed to me (as we did with buildd/wanna-build), or just a stub email telling me that the build of package "foo" failed, with a URL to click on to see the log, I'm not too picky.

[Celso Providelo (cprov)]

Actually, the idea of "Builder Failure subscription" is very nice. I think we can implement it very quickly . It would be sending a report email containing the build name, times related it and a link to the buildlog url. Does it cover your request ?

[Matt Zimmerman (mdz)]

Yes, that sounds like it would be sufficient. Adam, do you agree?

[Celso Providelo (cprov)]

Anyway it needs a implementation plan, specification, to avoid code duplication.

Feel free to increase the priority of this bug if you think it's necessary, because it's not my schedulle for this week.

[Matt Zimmerman (mdz)]

On Wed, Apr 26, 2006 at 07:28:40PM -0000, Celso Providelo wrote:
> Anyway it needs a implementation plan, specification, to avoid code duplication.
>
> Feel free to increase the priority of this bug if you think it's necessary, because it's not my schedulle for this week.

Adam, how bad does it hurt?

--
 - mdz

[Adam Conrad (adconrad)]

The downside of a link URL rather than an actual copy of the buildlog is that I can't then use any automated procmail-driven recipes to search build logs for common failures or other such fun.

I can, on the flipside, see that you don't want everyone subscribed to build failures to get a full log, as you'd be generating a LOT of mail that way.

Perhaps a configurable option when subscribing to build failures, off by default, with a blinking warning that "sending the full build log can generate several megabytes of mail PER FAILURE, only do this if you're sure that's what you want and need" would suffice to make everyone happy?

As for urgency, I currently get by with sifting through recent failures on the web UI, which isn't ideal, but it works for now. I'd rather see this implemented correctly than quickly.

[Christian Reis (kiko)]

Configurable options are often more work than predicted, so avoid it if possible.

[Matt Zimmerman (mdz)]

https://launchpad.net/products/soyuz/+spec/build-failure-process

[Celso Providelo (cprov)]

wip in `build-failure-notification`

[Malcolm Cleaton (malcolmcleaton)]

Nearly fix released; fix code is out there, but set to just mail us, for live testing. Will be released v.soon now.

[Matt Zimmerman (mdz)]

How has the testing progressed? Can we expect this to be deployed in an upcoming rollout?

[Celso Providelo (cprov)]

Not as fast as expected, because lot of things needs to be tested this time, the clean up done during the sprint affected very sensible parts of soyuz.

They can't be deployed w/o full end-to-end tests in dogfood (actually soyuz is severely broken and I'm glad we were exposed to the errors before flying into production)

So, build-failure-notification were affected by the pending changes, its deployment needs wait this major changes.

If you desperatelly need b-f-n, talk with Adam to include your or other almost-public mbox in the lp_buildd+admins@drescher alias. Remember it still spamming people when we violate P-a-s.