track job duplications
openqa should track duplications of a job so one can see if someone restarted a job or if openqa already restarted the job itself because it crashed.
#2 Updated by ancorgs over 8 years ago
Duplicating job could be ok if we are able to easily determine which jobs are still relevant and which ones are just simply "old stuff". It's easy if you have a "line" of duplications. I mean, something like A duplicated into B and B duplicated into C and so on. In this case, the only relevant one is the one that have never been cloned or, in some cases, also those which a running or scheduled duplicated. The problem with the current model is that it allows more than one duplication for a given job. So instead of having a line, you can have something like:
- A duplicated into B.
- A duplicated again into C.
- C duplicated into D.
No way to know what is still relevant in a simple way.
So, I think we should never allow more than one duplicated per job, so the sequence is clear. At database level, there are several alternative implementations, but before proceeding I want to be sure that we all agree in that point.
#3 Updated by lnussel over 8 years ago
So, I think we should never allow more than one duplicated per job, so the
sequence is clear. At database level, there are several alternative
implementations, but before proceeding I want to be sure that we all agree in
Fair enough. I can't think of a reason why we'd need to duplicate jobs more
than one. I guess we'll have a prominent link to the new job when viewing a
duplicated one anyways.
#4 Updated by ancorgs over 8 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 50
Correct and safe duplication using database transactions and optimistic locking implemented with tests. Just one hour of work for somebody knowing DBIx::Class and Perl. Almost a whole day to me :-(. Time to do something useful with the new clone_id.