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
- Does it make sense to have more than COMPLETED and FAILED outcomes initially?
- 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
- 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, ...)
We added a new step to dev yesterday.