Added by coolo almost 10 years ago. Updated almost 8 years ago.
0%
Description
It would be good to display in the job which worker ran the job (especially if it misbehaved). For this it would be good not to reset $job->worker when it's done.
As we have many places where the existance of $job->worker marks a running job, we would need to add a job_id to the worker table, so we can check for $job->worker->job == $job I guess.
I assume this is done with commit ddb4f70c1951068624c59e9cfd635bc5c9708c13
Author: Stephan Kulow coolo@suse.de
Date: Wed Jun 8 06:48:56 2016 +0200
Move Jobs::worker_id to Worker::job_id
And add unique constraint to the job_id in the workers table (which is
much smaller)
?
please close if done.
It's not. But it's prepared now as there is no Job::worker_id anymore with a meaning - now we can freely add it to be displayed.
When you fix the t_finished of cancelled jobs, you can add that too.
Not sure whether it makes sense to store the worker ID. When checking the test results the worker might have already been deleted from the workers table and maybe re-added under another ID. So it would make more sense to store the actual string to be displayed, eg. 'g182:1'. I would call the column last_assigned_worker to avoid confusion with the relation which is already present.
I see the point of avoiding an ID, but if you delete a worker from the table then all the jobs associated with it loose the information. I don't know anything about g182:1 anyway. Having an id makes sure we can link to it directly instead of mapping it. But I don't mind either.
What I do mind though is the last_ prefix - either there is a worker accociated to the job or there is not. But there is no last one.
but if you delete a worker from the table then all the jobs associated with it loose the information.
That is exactly what I'm trying to avoid.
I don't know anything about g182:1 anyway.
'g182:1' was just an example taken from my local instance.
Having an id makes sure we can link to it directly instead of mapping it.
Do you have another use-case in mind which would require more information about the worker than we would store in the string? If yes, the required mapping would be worse option I guess.
either there is a worker accociated to the job or there is not
So I'll call it just associated_worker. (Some prefix is required to distinguish from already existing worker.)
PR: https://github.com/os-autoinst/openQA/pull/1079
Decided to store IDs now instead of strings because of #13144.
EDIT (okurz): Please reference tickets with #<nr> to make it proper links with hover information.
Merged and works in production: https://openqa.suse.de/tests/677617