Project

General

Profile

Actions

action #138203

closed

coordination #58184: [saga][epic][use case] full version control awareness within openQA

coordination #48641: [epic] Trigger openQA tests in pull requests of any product github pull request

[openQA-in-openQA] CI jobs show error but don't fail the CI job as they should *and* openqa_install+publish missing size:M

Added by okurz about 1 year ago. Updated 11 months ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
Feature requests
Target version:
Start date:
2023-10-18
Due date:
% Done:

0%

Estimated time:

Description

https://progress.opensuse.org/issues/138203

Observation

https://github.com/os-autoinst/os-autoinst-distri-openQA/actions/runs/6560371820/job/17817854926?pr=147#step:5:11 says

{"count":4,"failed":[{"error_message":"The PUBLISH_HDD_1 cannot include \/ in value at \/usr\/share\/openqa\/script\/..\/lib\/OpenQA\/Schema\/ResultSet\/Jobs.pm line 122.\n","job_name":"openqa_install+publish"}],"ids":[3655002,3655003,3655004,3655005],"scheduled_product_id":339600}

maybe that's the reason why openqa_install+publish does not show up?

Acceptance criteria

  • AC1: error messages returned from the openQA API cause the CI pipeline to abort
  • AC2: A default openQA installation using apache is running as part of every pull request to os-autoinst-distri-openQA

Suggestions

  • Maybe we don't want to call "openqa_install+publish" directly in pull requests as that would take rather long to publish a qcow image and also it might overwrite the production one based on how PUBLISH_HDD_1 is configured. But on the other hand having a qcow file published that one can use directly for investigation and development would be nice. We should check how long it takes with/without publishing and decide what is the good approach for pull request triggered tests and ensure that we do have a default openQA installation using apache is running as part of every pull request to os-autoinst-distri-openQA
  • Ensure that in the CI job errors abort the CI with according error as well so that such errors don't go unnoticed (change openqa-cli exit code in case of errors)

Related issues 1 (0 open1 closed)

Related to openQA Project - action #126680: [openQA-in-openQA] no candidate needle with tag(s) 'boot-menu, openqa-desktop' matched in worker size:MResolvedjbaier_cz

Actions
Actions #1

Updated by jbaier_cz 12 months ago

  • Related to action #126680: [openQA-in-openQA] no candidate needle with tag(s) 'boot-menu, openqa-desktop' matched in worker size:M added
Actions #2

Updated by okurz 12 months ago

  • Priority changed from Normal to High
  • Target version changed from Tools - Next to Ready

this should help with #126680

Actions #3

Updated by tinita 12 months ago

  • Subject changed from [openQA-in-openQA] CI jobs show error but don't fail the CI job as they should *and* openqa_install+publish missing to [openQA-in-openQA] CI jobs show error but don't fail the CI job as they should *and* openqa_install+publish missing size:M
  • Description updated (diff)
  • Status changed from New to Workable
Actions #4

Updated by jbaier_cz 12 months ago

  • Assignee set to jbaier_cz
Actions #5

Updated by jbaier_cz 12 months ago

  • Status changed from Workable to In Progress

I was trying to understand the problem and the root cause is a combination of two commits:

The straight-forward fix probably is to not use a full URL for build name. I will try that and then proceed with other improvements.

Actions #6

Updated by jbaier_cz 12 months ago

I guess the quick fix to unblock the pipelines would be: https://github.com/os-autoinst/os-autoinst-distri-openQA/pull/155

Actions #7

Updated by jbaier_cz 12 months ago

  • Status changed from In Progress to Feedback

openqa-cli schedule fail improved inside https://github.com/os-autoinst/openQA/pull/5390, that should also help with the AC1

Actions #8

Updated by jbaier_cz 11 months ago

  • Status changed from Feedback to Resolved

Error messages from openqa-cli schedule now cause exit code 1, which should terminate the github pipeline; in the BUILD variable, '/' will be replaced with ':', so the HDD name should be safe. The time difference between the publish job and the second longest job is only a few minutes (13 vs 18 minutes) so I guess we can keep the benefits of having an HDD file for debugging. We can reiterate if the amount of PRs for this project grows and if we want to spare 5 minutes in the pipeline.

Actions

Also available in: Atom PDF