David,
I'll go ahead a post Shinya's reply to the support case:
Hi David,
The approach I would personally take, in that case, would be to
implement the test in the back-end code of a custom jobtype-- I think
that's the most straightforward way to approach it. It does mean
that it will require a custom back-end, but if the code is modularized
and put in a library of some sort, your developers would only need
to call that same function in each custom backend code.
An example of such a library function would be:
def myreportframe( work, exitcode ):
work['status'] = "failed"
if exitcode == 0:
work['status'] = "complete"
elif exitcode == 2:
work['status'] = "pending"
qb.reportwork(work)
Even if you're approaching it with a callback, you'd really need
some sort of custom back-end in order to feedback a per-frame status,
because the stock jobtypes only report the Qube preset status (i.e,
such as "failed", "complete", "killed"), since most of our jobtypes'
frame processing don't involve "process exit codes".
I guess you could approach it with a callback, as you originally proposed,
but I think that would complicate things. With that approach, you'd
still need a custom jobtype backend to feedback data in the "resultpackage"
that I mentioned earlier, and then the job's callbacks (that are submitted
with the job) would access that data and do something with it when they run.
As a future enhancement, I think we (PipelineFX) should improve the "cmdrange"
jobtype so that each frame, after being processed, will feedback its "exit code"
in, say, "work[resultpackage][exitcode]"-- I'll file a feature request.
-shinya.
