Project

General

Profile

action #92905

openqa-investigate creates jobs with wrong Git hash when triggered for jobs which already have a CASEDIR set to a git repo

Added by mkittler 2 months ago. Updated about 2 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Feature requests
Target version:
Start date:
2021-05-20
Due date:
2021-06-15
% Done:

0%

Estimated time:
Difficulty:

Description

Observation

This appears to happen if the involved original jobs have a custom CASEDIR pointing to a different repository, e.g. CASEDIR=https://github.com/dzedro/os-autoinst-distri-opensuse.git#15_sp3 (example from production: https://openqa.suse.de/tests/6064992).

In the mentioned example the created investigation job has the setting CASEDIR=https://github.com/os-autoinst/os-autoinst-distri-opensuse.git#1dbcdaba78224ab418c99efdd6fedcf0acda122c assigned which is wrong in this case so the job incompletes (with reason isotovideo died: Could not find '1dbcdaba78224ab418c99efdd6fedcf0acda122c' in complete history at /usr/lib/os-autoinst/OpenQA/Isotovideo/Utils.pm line 96., see https://openqa.suse.de/tests/6066691). The custom repository github.com/dzedro/os-autoinst-distri-opensuse should have been kept here because the last good job already had it as well. Of course if the last good job would have actually been using github.com/os-autoinst/os-autoinst-distri-opensuse then this repository would have been actually been correct. The other jobs which are created should of course be considered as well (e.g. https://openqa.suse.de/tests/6066693 incompleted here as well).

I'm not sure how much effort it will be to pick the right repository correctly in any case. If it is not feasible we could also ignore jobs using custom repositories (or when a related job like the last good is using a custom repository).

Acceptance criteria

  • AC1: No openqa-investigate jobs triggered with wrong repo for custom CASEDIR jobs
  • AC2: openqa-investigate jobs are triggered with same repo as original jobs

Suggestions

  • First we should prevent wrong jobs to be triggered. Better to identify such jobs and not trigger openqa-investigate jobs
  • As okurz foresees that eventually we will need "custom" repos in more cases we should fix the case as well

History

#1 Updated by VANASTASIADIS 2 months ago

  • Category set to Concrete Bugs
  • Assignee set to mkittler
  • Target version set to Ready

mkittler, is this related to what you're working on now? If not, feel free to unassign the ticket.

#2 Updated by mkittler 2 months ago

  • Assignee deleted (mkittler)

When I found #93101 I also thought it would be a duplicate of this ticket. However, #93101 is really just about jobs with custom CASEDIR being handled incorrectly while this ticket is about the CASEDIR itself being assigned incorrectly.

#3 Updated by okurz 2 months ago

  • Subject changed from openqa-investigate creates jobs with wrong Git hash to openqa-investigate creates jobs with wrong Git hash when triggered for jobs which already have a CASEDIR set to a git repo
  • Description updated (diff)
  • Category changed from Concrete Bugs to Feature requests
  • Status changed from New to Workable

#4 Updated by mkittler about 2 months ago

  • Status changed from Workable to In Progress
  • Assignee set to mkittler

#6 Updated by openqa_review about 2 months ago

  • Due date set to 2021-06-15

Setting due date based on mean cycle time of SUSE QE Tools

#7 Updated by mkittler about 2 months ago

  • Status changed from In Progress to Feedback

#8 Updated by mkittler about 2 months ago

  • Status changed from Feedback to Resolved

It seems to work, e.g. the investigation jobs (retry and last good) for the job https://openqa.suse.de/tests/6232846#comments have been triggered against the custom repository (https://github.com/jlausuch/os-autoinst-distri-opensuse.git in both cases). Here the investigation job for the last good incompleted nevertheless. The commit hash of the last good has been set correctly (according to the info from the investigation tab). Likely the commit of the last good has just already been deleted/overridden in the meantime. I think that's something we cannot prevent and have to live with.

Also available in: Atom PDF