Decouple ExecDB from Buildbot
Needs ReviewPublic

Authored by jskladan on Feb 23 2017, 12:35 PM.

Details

Summary

Instead of consuming the Buildbot push notification stream, ExecDB provides a comprehensive API to

  • create new job (returns uuid)
  • update job state (running, finished, ...)
  • create and update steps (set to finished, duration, outcome)

The default behavior tries to make stuff as reasonable as possibe:

  • creating a new step marks the previous one as succesfully completed (if not alredy marked as finished)
    • so does setting the job to finished
  • on top of setting the job's outcome to a specific value, there is _COMPUTED_ special value that inferres the outcome based on the steps

UI still updates dynamically in the job detail view.

I'd like to discuss some of the implementation details

  1. Does it make sense to have more than COMPLETED and FAILED outcomes initially?
  2. Should status and outcome be separated, as they are now (not in DB, but in the user-facing objects)?
    • My idea here is that status would be able to be SCHEDULED and RUNNING as now, but instead of FINISHED it would return the outcome value (COMPLETED, FAILED, ...)
    • The current state needs you to 'care about' two different values, but the more I think about it, the less sense it makes to have that separation
  3. Does it make sense to store the item and/or item_type? I see some value there to be able to search for "did any jobs run on this stuff, without reporting results" so this is why I kept it so far. But I guess we can revisit this once we decide on the way to solve passing 'random arguments' to libtaskotron.

UNFINISHED:

  • API documentation
  • search over jobs (name, item, state, ...)
Test Plan

Tested locally via test_api.py

Diff Detail

Repository
rEXECDB execdb
Branch
feature/pony
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 1075
Build 1075: arc lint + arc unit
jskladan retitled this revision from to Decouple ExecDB from Buildbot.Feb 23 2017, 12:35 PM
jskladan updated this object.
jskladan edited the test plan for this revision. (Show Details)

Macro idontalways: I don't always understand the code but I can always complain

Does it make sense to have more than COMPLETED and FAILED outcomes initially?

I think having just these two is fine, at least for now. The idea is that these include the crash/failure reason in the future, right? Like FAILED NETWORK, etc (do we have that documented somehwhere? I already forgot it)?

There might be some confusion between FAILED outcome in execdb and FAILED in resultsdb (also, we use the same term for them).

Should status and outcome be separated, as they are now (not in DB, but in the user-facing objects)?
My idea here is that status would be able to be SCHEDULED and RUNNING as now, but instead of FINISHED it would return the outcome value (COMPLETED, FAILED, ...)
The current state needs you to 'care about' two different values, but the more I think about it, the less sense it makes to have that separation

That depends on the answer for the question above. IIUIC, I'd do it like: SCHEDULED, RUNNING, COMPLETED or FAILED. And then have the failure reason as a separate field.

Does it make sense to store the item and/or item_type? I see some value there to be able to search for "did any jobs run on this stuff, without reporting results" so this is why I kept it so far. But I guess we can revisit this once we decide on the way to solve passing 'random arguments' to libtaskotron.

The first time a build/update doesn't receive any result and somebody asks us "why my htop-1.2-3.fc25 didn't receive any test feedback?", we'll need to be able to search that up somehow. Do you know about any better ways to do it outside of storing item/item_type (and possibly other properties) in execdb, at least for failed jobs?

execdb/cli.py
125–134

We added a new step to dev yesterday.

152

This will crash if the step is not listed. Let's not.

mkrizek resigned from this revision.Thu, Jul 13, 9:03 AM