Do not retry jobs that were obsoleted

The 'obsoleted' result indicates the job was cancelled because a
new schedule request for the same scenario came in. In this case
it probably doesn't make sense to auto-retry the cancelled job
because the new request indicates the admin wants the job run
with the new settings.

See: https://progress.opensuse.org/issues/164613

Signed-off-by: Adam Williamson <[email protected]>

lib/OpenQA/Schema/Result/Jobs.pm

@@ -575,7 +575,8 @@ sub is_ok ($self) {
 sub is_ok_to_retry ($self) {
     return 1 unless my $result = $self->result;
     return 0 if grep { $_ eq $result } OK_RESULTS;    # retry is not needed if job is ok
-    return 0 if $result eq USER_CANCELLED;    # retry is not needed if job is user-cancelled
+    return 0 if $result eq USER_CANCELLED;    # retry is not needed if job is user-cancelled...
+    return 0 if $result eq OBSOLETED;    # ...or obsoleted
     return 1;
 }
 

t/10-jobs.t

@@ -831,6 +831,10 @@ subtest 'job setting based retriggering' => sub {
     $job->done(result => USER_CANCELLED);
     perform_minion_jobs($minion);
     is $jobs->count, $jobs_nr + 1, 'no additional job retriggered if USER_CANCELLED (with retry)';
+    $job->update({state => SCHEDULED, result => NONE});
+    $job->done(result => OBSOLETED);
+    perform_minion_jobs($minion);
+    is $jobs->count, $jobs_nr + 1, 'no additional job retriggered if OBSOLETED (with retry)';
     my $get_jobs = sub ($task) {
         $minion->backend->pg->db->query(q{select * from minion_jobs where task = $1 order by id asc}, $task)->hashes;
         # note: Querying DB directly as `$minion->jobs({tasks => [$task]})` does not return parents.