Project

General

Profile

action #64961

test fails in installation - cannot find autoinst.xml. server returned code 404

Added by mlin7442 about 1 year ago. Updated 9 months ago.

Status:
Resolved
Priority:
High
Assignee:
-
Category:
Concrete Bugs
Target version:
Start date:
2020-03-29
Due date:
% Done:

0%

Estimated time:
Difficulty:

Description

Observation

openQA test in scenario opensuse-15.2-DVD-x86_64-autoyast_reinstall_gnome@64bit fails in
installation

Should be as easy as using basename to get only filename and pass that to the http://open.qa/api/testapi/#_autoinst_url method.

Please, note, that it requires latest openQA as it has new behavior (which caused this failure originally).

Test suite description

Reproducible

Fails since (at least) Build 615.3

Expected result

Last good: 613.2 (or more recent)

Further details

Always latest result in this scenario: latest (was: Leap 15.2 latest )

History

#1 Updated by riafarov about 1 year ago

  • Subject changed from test fails in installation - cannot find autoinst.xml. server returned code 404 to [functional][y] test fails in installation - cannot find autoinst.xml. server returned code 404
  • Due date set to 2020-04-21
  • Target version set to Milestone 35+

This is related to the ASSET expansion change done recently. We will take a look.

#2 Updated by riafarov about 1 year ago

  • Description updated (diff)
  • Status changed from New to Workable
  • Priority changed from Normal to High
  • Estimated time set to 3.00 h

#3 Updated by riafarov about 1 year ago

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

#4 Updated by riafarov about 1 year ago

  • Status changed from In Progress to Feedback

#5 Updated by riafarov about 1 year ago

  • Status changed from Feedback to Resolved

#6 Updated by okurz 11 months ago

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: autoyast_reinstall_gnome
https://openqa.opensuse.org/tests/1260381

To prevent further reminder comments one of the following options should be followed:

  1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
  2. The openQA job group is moved to "Released"
  3. The label in the openQA scenario is removed

#7 Updated by mlin7442 10 months ago

  • Status changed from Resolved to Feedback

#8 Updated by riafarov 10 months ago

  • Project changed from openQA Tests to openQA Project
  • Subject changed from [functional][y] test fails in installation - cannot find autoinst.xml. server returned code 404 to test fails in installation - cannot find autoinst.xml. server returned code 404
  • Due date deleted (2020-04-21)
  • Category deleted (Bugs in existing tests)
  • Assignee deleted (riafarov)
  • Target version changed from Milestone 35+ to future
  • Estimated time deleted (3.00 h)

Can anyone from the tools team take a look? Even when installer works, we cannot reach AY profile from the worker: https://openqa.opensuse.org/tests/1314297#step/installation/1
Was there any change in the asset handling?

#9 Updated by riafarov 10 months ago

  • Category set to Concrete Bugs
  • Status changed from Feedback to New

#10 Updated by cdywan 10 months ago

I think gh#os-autoinst/os-autoinst#1381 was meant to address that but fell off the radar.

#11 Updated by okurz 9 months ago

  • Description updated (diff)
  • Status changed from New to Resolved

I pinged in https://github.com/os-autoinst/os-autoinst/pull/1381#issuecomment-664973820 asking about further plans for the PR.

The corresponding "latest" test from Tumbleweed would be https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensuse&flavor=DVD&machine=64bit&test=autoyast_reinstall_gnome&version=Tumbleweed , probably a better match than Leap 15.2 which is finished in development.

https://openqa.opensuse.org/tests/1316996#step/installation/1 shows that the autoyast profile can be reached from the installer so I assume the original issue is fixed but I am not sure if this now was a change in test code or our production code.

I will set the issue to "Resolved" as the issue seems to be gone but anyone is welcome to clarify what step was needed to fix that or even come up with further tasks that should be followed.

Also available in: Atom PDF