The http status notifier in old buildbot (0.8.x) has changed for the new buildbot (0.9+). The new httpStatusPush service has a different data payload than the one that execdb is designed for.
The data needed may or may not be in the new-style json payload, the structure is definitely different.
Make the two work together: this will involve changes to execdb, may involve changes to the json payload sent by the statusPush service.
As I dig into this more, I'm questioning what we want execdb to reflect and be. IIRC, it was put together following the status push method of old buildbot.
The new buildbot status push code only pushes status on build creation and build completion, not with every buildstep's completion as old buildbot did.
From what I can see in the manual and code, it would be possible to write a service plugin for new buildbot that pushes status on completion of every step but I'm left with the question of "do we really want to do that?"
Does anyone have thoughts on whether we want to keep execdb as close to the same as we possibly can or change it so that it only deals with state changes associated with the creation and completion of a build?
I honestly do not care at all, I'm not even that sure the "steps" in execdb get used for anything, really. But maybe @kparal does look into it from time to time?
IMO the "failed jobs" notifications we get are from buildbot anyway (correct me if i'm wrong), and ExecDB really mostly is a delegated just to creating that UUID (and maybe sending some FedMsg notifications?) And me being a bit brave today, I even think that it could all be just done from Buildbot...
What do you think about that?
I suspect that you're right and we could put the UUID stuff into buildbot but I'm not sure that would be any less work.
I think that the new status pusher sends the same bits as the old one did, it just won't happen as the job runs. The "build completed" message will contains all the data and is only sent upon completion.
I very rarely use execdb when debugging something. I'll definitely not miss the gradual progress being shown. If the new status pusher can give us job start and job end, that's completely fine for us, at this point, I believe.
Metadata Update from @kparal: - Issue assigned to tflink - Issue priority set to: High - Issue tagged with: infra
Cool, I'll get a patch ready for execdb, then
Metadata Update from @tflink: - Assignee reset - Issue untagged with: infra - Issue priority set to: None (was: High)
This has been fixed in: https://pagure.io/taskotron/execdb/pull-request/17
Metadata Update from @kparal: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.