openSUSE Project Management Tool: Issueshttps://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842020-06-30T09:39:05ZopenSUSE Project Management Tool
Redmine openQA Tests - action #68527 (Feedback): [qe-core][functional] YAML schedule for test modules in ...https://progress.opensuse.org/issues/685272020-06-30T09:39:05ZSLindoMansillaslindomansilla@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<ol>
<li>Avoid main.pm</li>
<li>Avoid <code>EXCLUDE_MODULES</code> (eg. <a href="https://progress.opensuse.org/issues/66209" class="external">https://progress.opensuse.org/issues/66209</a>, <a href="https://gitlab.suse.de/qsf-u/qa-sle-functional-userspace/-/blob/master/functional_sle15_jobgroup.yaml#L16" class="external">https://gitlab.suse.de/qsf-u/qa-sle-functional-userspace/-/blob/master/functional_sle15_jobgroup.yaml#L16</a>)</li>
</ol>
<a name="List-of-jobs-scheduled-for-userspace-job-group"></a>
<h2 >List of jobs scheduled for userspace job group<a href="#List-of-jobs-scheduled-for-userspace-job-group" class="wiki-anchor">¶</a></h2>
<a name="SLE-15-SP2-Flavor-Full"></a>
<h4 >SLE 15-SP2 Flavor Full<a href="#SLE-15-SP2-Flavor-Full" class="wiki-anchor">¶</a></h4>
<table><thead>
<tr>
<th>Test suite name</th>
<th>maintainers</th>
<th>aarch64</th>
<th>ppc64le</th>
<th>s390x</th>
<th>x86_64</th>
<th>PR</th>
</tr>
</thead><tbody>
<tr>
<td>minimal+proxy_SCC-postreg_SUSEconnect</td>
<td>riafarov</td>
<td>YAML (openQA test suite definition)</td>
<td>YAML (openQA test suite definition)</td>
<td>YAML (openQA test suite definition)</td>
<td>YAML (openQA test suite definition)</td>
<td><a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/10610" class="external">https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/10610</a></td>
</tr>
<tr>
<td>skip_registration+workaround_modules</td>
<td>slindomansilla</td>
<td>main.pm</td>
<td>main.pm</td>
<td>main.pm</td>
<td>main.pm</td>
<td><a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/10611" class="external">https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/10611</a></td>
</tr>
<tr>
<td>extra_tests_draut</td>
<td>?</td>
<td>main.pm</td>
<td>main.pm</td>
<td>main.pm</td>
<td>main.pm</td>
<td><a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/12368" class="external">https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/12368</a></td>
</tr>
<tr>
<td>networkd</td>
<td>?</td>
<td>main.pm</td>
<td>main.pm</td>
<td>main.pm</td>
<td>main.pm</td>
<td><a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/12380" class="external">https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/12380</a></td>
</tr>
<tr>
<td>ovs</td>
<td>?</td>
<td>main.pm</td>
<td>main.pm</td>
<td>main.pm</td>
<td>main.pm</td>
<td><a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/12393" class="external">https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/12393</a></td>
</tr>
<tr>
<td>qemu</td>
<td>?</td>
<td>main.pm</td>
<td>main.pm</td>
<td>main.pm</td>
<td>main.pm</td>
<td><a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/12402" class="external">https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/12402</a></td>
</tr>
<tr>
<td>toolkits</td>
<td>?</td>
<td>main.pm</td>
<td>main.pm</td>
<td>main.pm</td>
<td>main.pm</td>
<td><a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/12425" class="external">https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/12425</a></td>
</tr>
</tbody></table>
openQA Tests - action #63649 (New): [qe-core][functional] Enhanced reboot_after_installationhttps://progress.opensuse.org/issues/636492020-02-20T13:41:14ZSLindoMansillaslindomansilla@suse.com
<a name="Tasks"></a>
<h2 >Tasks<a href="#Tasks" class="wiki-anchor">¶</a></h2>
<ol>
<li>reboot_after_installation always received from a previous module, a known system state, which is not changing over time.</li>
<li>reboot_after_installation always left the system for a following module, in a known system state, which is not changing over time.</li>
</ol>
<a name="Sugguestion"></a>
<h2 >Sugguestion<a href="#Sugguestion" class="wiki-anchor">¶</a></h2>
<ul>
<li>reboot_after_installation will end on grub menu.</li>
<li>If grub menu has a timeout, it will stop the timeout by pressing a key (esc, up?)</li>
<li>The next module has to take over from grub <strong>grub_test</strong></li>
</ul>
<a name="Latest"></a>
<h2 >Latest<a href="#Latest" class="wiki-anchor">¶</a></h2>
<ul>
<li><a href="https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensuse&flavor=KDE-Live&machine=64bit-2G&test=kde-live_installation&version=15.1#step/reboot_after_installation/6" class="external">https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensuse&flavor=KDE-Live&machine=64bit-2G&test=kde-live_installation&version=15.1#step/reboot_after_installation/6</a></li>
</ul>
openQA Tests - action #62480 (Workable): [qe-core][functional] Implement functions that return th...https://progress.opensuse.org/issues/624802020-01-21T14:31:43ZSLindoMansillaslindomansilla@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>At the moment, the TTY numbers are assigned to consoles when they are added (<a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/lib/susedistribution.pm#L454" class="external">https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/lib/susedistribution.pm#L454</a>)</p>
<pre><code class="perl syntaxhl" data-language="perl"> <span class="nv">$self</span><span class="o">-></span><span class="nv">add_console</span><span class="p">('</span><span class="s1">install-shell</span><span class="p">',</span> <span class="p">'</span><span class="s1">tty-console</span><span class="p">',</span> <span class="p">{</span><span class="s">tty</span> <span class="o">=></span> <span class="mi">2</span><span class="p">});</span>
<span class="nv">$self</span><span class="o">-></span><span class="nv">add_console</span><span class="p">('</span><span class="s1">installation</span><span class="p">',</span> <span class="p">'</span><span class="s1">tty-console</span><span class="p">',</span> <span class="p">{</span><span class="s">tty</span> <span class="o">=></span> <span class="nv">check_var</span><span class="p">('</span><span class="s1">VIDEOMODE</span><span class="p">',</span> <span class="p">'</span><span class="s1">text</span><span class="p">')</span> <span class="p">?</span> <span class="mi">1</span> <span class="p">:</span> <span class="mi">7</span><span class="p">});</span>
<span class="nv">$self</span><span class="o">-></span><span class="nv">add_console</span><span class="p">('</span><span class="s1">install-shell2</span><span class="p">',</span> <span class="p">'</span><span class="s1">tty-console</span><span class="p">',</span> <span class="p">{</span><span class="s">tty</span> <span class="o">=></span> <span class="mi">9</span><span class="p">});</span>
<span class="c1"># On SLE15 X is running on tty2 see bsc#1054782</span>
<span class="nv">$self</span><span class="o">-></span><span class="nv">add_console</span><span class="p">('</span><span class="s1">root-console</span><span class="p">',</span> <span class="p">'</span><span class="s1">tty-console</span><span class="p">',</span> <span class="p">{</span><span class="s">tty</span> <span class="o">=></span> <span class="nv">get_root_console_tty</span><span class="p">});</span>
<span class="nv">$self</span><span class="o">-></span><span class="nv">add_console</span><span class="p">('</span><span class="s1">user-console</span><span class="p">',</span> <span class="p">'</span><span class="s1">tty-console</span><span class="p">',</span> <span class="p">{</span><span class="s">tty</span> <span class="o">=></span> <span class="mi">4</span><span class="p">});</span>
<span class="nv">$self</span><span class="o">-></span><span class="nv">add_console</span><span class="p">('</span><span class="s1">log-console</span><span class="p">',</span> <span class="p">'</span><span class="s1">tty-console</span><span class="p">',</span> <span class="p">{</span><span class="s">tty</span> <span class="o">=></span> <span class="mi">5</span><span class="p">});</span>
<span class="nv">$self</span><span class="o">-></span><span class="nv">add_console</span><span class="p">('</span><span class="s1">displaymanager</span><span class="p">',</span> <span class="p">'</span><span class="s1">tty-console</span><span class="p">',</span> <span class="p">{</span><span class="s">tty</span> <span class="o">=></span> <span class="mi">7</span><span class="p">});</span>
<span class="nv">$self</span><span class="o">-></span><span class="nv">add_console</span><span class="p">('</span><span class="s1">x11</span><span class="p">',</span> <span class="p">'</span><span class="s1">tty-console</span><span class="p">',</span> <span class="p">{</span><span class="s">tty</span> <span class="o">=></span> <span class="nv">get_x11_console_tty</span><span class="p">});</span>
<span class="nv">$self</span><span class="o">-></span><span class="nv">add_console</span><span class="p">('</span><span class="s1">tunnel-console</span><span class="p">',</span> <span class="p">'</span><span class="s1">tty-console</span><span class="p">',</span> <span class="p">{</span><span class="s">tty</span> <span class="o">=></span> <span class="mi">3</span><span class="p">})</span> <span class="k">if</span> <span class="nv">get_var</span><span class="p">('</span><span class="s1">TUNNELED</span><span class="p">');</span>
</code></pre>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1:</strong> A hash in <code>/lib/Utils/TTY.pm</code> contains the assignment between console names and TTY numbers</li>
<li><strong>AC2:</strong> <code>/lib/Utils/TTY.pm</code> is properly documented</li>
</ul>
<a name="Considerations"></a>
<h2 >Considerations<a href="#Considerations" class="wiki-anchor">¶</a></h2>
<ul>
<li>Before making code changes, explain the team the idea of implementing this to avoid wasting time on a PR review.</li>
</ul>
openQA Tests - action #59014 (New): [qe-core][functional] Enhanced grub_test modulehttps://progress.opensuse.org/issues/590142019-11-04T10:11:34ZSLindoMansillaslindomansilla@suse.com
<a name="Tasks"></a>
<h2 >Tasks<a href="#Tasks" class="wiki-anchor">¶</a></h2>
<ol>
<li>grub_test always received from a previous module, a known system state, which is not changing over time.</li>
<li>grub_test always left the system for a following module, in a known system state, which is not changing over time.</li>
</ol>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>Make grub_test wait for first line from the kernel, before handing over the control to the next module to ensure that the "enter" key was really pressed and got to the SUT.</li>
<li>Implement <code>NON_INTERACTIVE</code> setting to not wait for dracut.</li>
</ul>
openQA Tests - action #55580 (Feedback): [qe-core][functional] Refactor susedistribution::x11_sta...https://progress.opensuse.org/issues/555802019-08-15T13:42:05Zszarate
<p>As a result of poo#54401, and <a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/8192" class="external">https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/8192</a> the proposed solution would help if spread to other areas. So making it more generic, and allow <code>x11_start_program</code> to support mistyping. </p>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>In the case of xterm, when command is not found, use <code>clear</code> instead of <code>esc</code>.</li>
<li>In the case of application launchers, press <code>esc</code> ensure desktop is matched, and try again like it was implemented for <a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/8192/files#diff-33406501a27b0aa9d7631e5a8037b2c4R29" class="external">firefox_audio</a>.</li>
</ul>
<p>Starting with application launchers would/should be the easier way to start. Building a small matrix of the desktops where it would be supported, would help a lot. </p>
<a name="Tasks"></a>
<h2 >Tasks<a href="#Tasks" class="wiki-anchor">¶</a></h2>
<ol>
<li>Building a small matrix of the desktops where it would be supported</li>
<li>Move the for loop of the retry inside x11_start_program</li>
</ol>
<a name="Supported-Desktops"></a>
<h2 >Supported Desktops<a href="#Supported-Desktops" class="wiki-anchor">¶</a></h2>
<ul>
<li>Gnome</li>
<li>KDE</li>
<li>MinimalX (not yet verified)</li>
</ul>
openQA Tests - action #51857 (Workable): [qe-core][functional] create scenario upgrade_tumbleweed...https://progress.opensuse.org/issues/518572019-05-22T15:14:03Zggardet_armguillaume.gardet@arm.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>As a release manager, I want to have a real use case scenario where a user has a released tumbleweed snapshot installed which is then upgraded to the to be released snapshot.</p>
<p><code>upgrade_tumbleweed</code> should use released ISO instead of tested ISO, otherwise, installer may fail to boot properly.</p>
<p>openQA test in scenario opensuse-Tumbleweed-NET-aarch64-create_hdd_tumbleweed@aarch64 fails in<br>
<a href="https://openqa.opensuse.org/tests/939148/modules/welcome/steps/9" class="external">welcome</a></p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC:</strong> The use case of upgrading a released snapshot to the snapshot to be tested is covered in openQA</li>
</ul>
<a name="Tasks"></a>
<h2 >Tasks<a href="#Tasks" class="wiki-anchor">¶</a></h2>
<ol>
<li>Proper scenario's name to be decided.</li>
<li>Monitor the snapshot releases, when a new snapshot is released save the corresponding qcow2 image in the fixed directory</li>
<li>Once there's a new snapshot released, remove the previous 'published' </li>
<li>Update the repositories</li>
</ol>
<a name="Reproducible"></a>
<h2 >Reproducible<a href="#Reproducible" class="wiki-anchor">¶</a></h2>
<p>Fails since Build <a href="https://openqa.opensuse.org/tests/887460" class="external">20190304</a></p>
<a name="Expected-result"></a>
<h2 >Expected result<a href="#Expected-result" class="wiki-anchor">¶</a></h2>
<p>Last good: <a href="https://openqa.opensuse.org/tests/869810" class="external">20190304</a></p>
<a name="Further-details"></a>
<h2 >Further details<a href="#Further-details" class="wiki-anchor">¶</a></h2>
<p>Always latest result in this scenario: <a href="https://openqa.opensuse.org/tests/latest?version=Tumbleweed&machine=aarch64&test=create_hdd_tumbleweed&flavor=NET&arch=aarch64&distri=opensuse" class="external">latest</a></p>
openQA Tests - action #51413 (New): [qe-core][functional] Automatic checks for missing documentat...https://progress.opensuse.org/issues/514132019-05-13T09:24:06ZSLindoMansillaslindomansilla@suse.com
<a name="AC"></a>
<h2 >AC<a href="#AC" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC:</strong> It is ensured, that everyone adding new functionality also documents it</li>
</ul>
<a name="Tasks"></a>
<h2 >Tasks<a href="#Tasks" class="wiki-anchor">¶</a></h2>
<ol>
<li>Create a mechanism that runs <a href="https://metacpan.org/pod/Pod::Checker" class="external">pod-checker</a> and shows a list of undocumented functions under /lib</li>
<li>PR are not able to be merged if the check doesn't pass (or is below under a certain threshold)</li>
</ol>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ol>
<li>Take into account situations where routines/function are so small that don't need documentation, <code>##nodoc</code> could be an option to indicate the parser, that the following method doesn't need to be checked.</li>
<li>Document methods in /lib where it would be useful.</li>
<li>Figure and propose a podchecker documentation format (and use that script to for the automated checks on travis) (see poo#50510)</li>
</ol>
openQA Tests - action #48566 (New): [qe-core][functional] Crosscheck workaround for bsc#980337 in...https://progress.opensuse.org/issues/485662019-03-01T06:47:54Zokurzokurz@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-15-SP1-Installer-DVD-aarch64-extra_tests_on_gnome@aarch64 in<br>
<a href="https://openqa.suse.de/tests/2470908/modules/user_defined_snapshot/steps/80" class="external">user_defined_snapshot</a> shows that we reached gdm successfully but we still report a soft_failure pointing to <a href="https://bugzilla.suse.com/show_bug.cgi?id=980337" class="external">bsc#980337</a> which looks wrong.</p>
<a name="Conditional-acceptance-criteria"></a>
<h2 >Conditional acceptance criteria<a href="#Conditional-acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>CC1:</strong> The bug is verified fixed and the record_soft_fail removed
or</li>
<li><strong>CC2:</strong> The bug is still valid reopen the bug</li>
</ul>
<a name="Reproducible"></a>
<h2 >Reproducible<a href="#Reproducible" class="wiki-anchor">¶</a></h2>
<p>Probably fails since SLE15 where the product eventually managed to boot successfully into gdm and we have not realized</p>
<a name="Expected-result"></a>
<h2 >Expected result<a href="#Expected-result" class="wiki-anchor">¶</a></h2>
<p>The bug should only be referenced in case we can <em>not</em> reach boot, or more specifically <em>not gdm</em></p>
<a name="Further-details"></a>
<h2 >Further details<a href="#Further-details" class="wiki-anchor">¶</a></h2>
<p>Always latest result in this scenario: <a href="https://openqa.suse.de/tests/latest?machine=aarch64&version=15-SP1&test=extra_tests_on_gnome&arch=aarch64&distri=sle&flavor=Installer-DVD" class="external">latest</a></p>
openQA Tests - action #48416 (New): [opensuse][leap] test fails in install_service - could not re...https://progress.opensuse.org/issues/484162019-02-26T08:13:06Zmlin7442mlin@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario opensuse-15.1-DVD-x86_64-zdup-Leap-42.2-gnome@64bit-2G fails in<br>
<a href="https://openqa.opensuse.org/tests/862634/modules/install_service/steps/8" class="external">install_service</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>Looks like this is happened on 42.2/42.3 upgrade scenario(sporadic), I can't figure out.</p>
<a name="Reproducible"></a>
<h2 >Reproducible<a href="#Reproducible" class="wiki-anchor">¶</a></h2>
<p>Fails since (at least) Build <a href="https://openqa.opensuse.org/tests/862634" class="external">419.1</a> (current job)</p>
<a name="Expected-result"></a>
<h2 >Expected result<a href="#Expected-result" class="wiki-anchor">¶</a></h2>
<p>Last good: <a href="https://openqa.opensuse.org/tests/860118" class="external">417.2</a> (or more recent)</p>
<a name="Further-details"></a>
<h2 >Further details<a href="#Further-details" class="wiki-anchor">¶</a></h2>
<p>Always latest result in this scenario: <a href="https://openqa.opensuse.org/tests/latest?version=15.1&test=zdup-Leap-42.2-gnome&arch=x86_64&distri=opensuse&machine=64bit-2G&flavor=DVD" class="external">latest</a></p>
openQA Tests - action #46988 (New): [qe-core][functional] Detect known bugs from system journalhttps://progress.opensuse.org/issues/469882019-02-01T11:57:40Zokurzokurz@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>See parent ticket <a class="issue tracker-6 status-3 priority-4 priority-default closed parent" title="coordination: [saga][epic] Detection of "known failures" for stable tests, easy test results review and easy tr... (Resolved)" href="https://progress.opensuse.org/issues/39719">#39719</a> . As test reviewers we want to have less work to label jobs for known issues that can be detected from the system journal which we also upload</p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC1:</strong> We have an easy way to reference bugs as soft-failures by looking at matching patterns in the system journal</li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>Take a look into the file <code>lib/known_bugs.pm</code> as introduced with 4fac2c92c</li>
<li>Extend pattern matching functionality to look into the system journal as well, maybe just use a matching pattern in the same file but used in the generic post_fail_hook that uploads the systemd journal, e.g. in lib/opensusebasetest.pm:problem_detection</li>
<li>Use example <a href="https://openqa.suse.de/tests/2429429#step/firefox/5" class="external">https://openqa.suse.de/tests/2429429#step/firefox/5</a> for detecting the firefox segfaulting on ppc64le</li>
<li>Use <a href="https://github.com/os-autoinst/os-autoinst/blob/master/testapi.pm#L232" class="external">force_soft_failure</a></li>
</ul>
openQA Tests - coordination #43889 (Blocked): [qe-core][epic][functional][virtio][wayland] openQA...https://progress.opensuse.org/issues/438892018-11-16T10:40:22Zszarate
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>While looking at the screenshot, openqa typed Hello World (from the logs), but in the screen Hello Wolrd is seen... causing the mismatch... </p>
<pre><code>[2018-11-15T22:51:12.695 CET] [debug] /var/lib/openqa/cache/openqa.suse.de/tests/sle/tests/x11/ooffice.pm:24 called utils::type_string_slow
[2018-11-15T22:51:12.695 CET] [debug] <<< testapi::type_string(string='Hello World!', max_interval=13, wait_screen_changes=0, wait_still_screen=0)
[2018-11-15T22:51:16.349 CET] [debug] /var/lib/openqa/cache/openqa.suse.de/tests/sle/tests/x11/ooffice.pm:25 called testapi::assert_screen
[2018-11-15T22:51:16.349 CET] [debug] <<< testapi::assert_screen(mustmatch='test-ooffice-2', timeout=30)
</code></pre>
<p>openQA test in scenario sle-15-SP1-Installer-DVD-x86_64-gnome_sled@laptop_64bit-virtio-vga fails in<br>
<a href="https://openqa.suse.de/tests/2262358/modules/ooffice/steps/6" class="external">ooffice</a></p>
<a name="Reproducible"></a>
<h2 >Reproducible<a href="#Reproducible" class="wiki-anchor">¶</a></h2>
<p>Fails since (at least) Build <a href="https://openqa.suse.de/tests/2262358" class="external">96.7</a> (current job)</p>
<a name="Expected-result"></a>
<h2 >Expected result<a href="#Expected-result" class="wiki-anchor">¶</a></h2>
<p>Last good: <a href="https://openqa.suse.de/tests/2260412" class="external">95.1</a> (or more recent)</p>
<a name="Further-details"></a>
<h2 >Further details<a href="#Further-details" class="wiki-anchor">¶</a></h2>
<p>Always latest result in this scenario: <a href="https://openqa.suse.de/tests/latest?machine=laptop_64bit-virtio-vga&arch=x86_64&version=15-SP1&test=gnome_sled&flavor=Installer-DVD&distri=sle" class="external">latest</a></p>
<p>possible misstype ninjakeys</p>
openQA Tests - coordination #40484 (New): [qe-core][functional][epic] Move different checks to se...https://progress.opensuse.org/issues/404842018-08-31T12:42:59Zriafarov
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>We test some UI features which affect many and sometimes all test suites. Best example is test for proceeding without accepting license. This is important check, whereas if we want to know overall status of the build, will break all the tests. <br>
In case it's located in a separate test suite, we could still validate this functionality, but don't affect other tests.<br>
Same is valid for scenarios when some problem makes testing complex, e.g. screensaver. If we have separate test covering screensaver, we have low risk of missing something and have better stability as do not have to apply additional actions for screensaver detection.</p>
<p>installer_extended is one of test suites which can be used for UI changes <a href="https://openqa.suse.de/tests/2163370" class="external">https://openqa.suse.de/tests/2163370</a></p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ol>
<li>All such non-functional checks are identified and either addressed using this ticket, or as a sub-ticket</li>
<li>Only relevant tests are affected when some feature is broken</li>
</ol>
openQA Tests - coordination #39302 (New): [qe-core][functional][opensuse][epic][medium] uefi upgr...https://progress.opensuse.org/issues/393022018-08-08T07:43:45Zlnussellnussel@suse.com
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>Ensure TW is a superset of Leap, i.e. add missing upgrade tests only on Leap to TW</li>
<li>If necessary according to lnussel add 42.1 upgrade tests by creating the assets somehow, manually or automatically</li>
</ul>
<a name="Further-details"></a>
<h2 >Further details<a href="#Further-details" class="wiki-anchor">¶</a></h2>
<a name="Original-observation"></a>
<h3 >Original observation<a href="#Original-observation" class="wiki-anchor">¶</a></h3>
<p>This problem affects O3 only (openqa.opensuse.org)<br>
When upgrading from any Leap version to TW.<br>
So, the assets are disk image with previous Leap installation.</p>
<p>In <a href="https://openqa.opensuse.org/tests/overview?distri=opensuse&version=15.1" class="external">https://openqa.opensuse.org/tests/overview?distri=opensuse&version=15.1</a></p>
<p>[2018-08-08T00:55:39.0872 CEST] [info] result: setup failure: Can't download <a href="mailto:opensuse-42.1-x86_64-Updates-20170213-1-cryptlvm@uefi.qcow2">opensuse-42.1-x86_64-Updates-20170213-1-cryptlvm@uefi.qcow2</a><br>
[2018-08-08T00:48:01.0851 CEST] [info] result: setup failure: Can't download <a href="mailto:opensuse-42.2-x86_64-Updates-20180206-1-cryptlvm@uefi.qcow2">opensuse-42.2-x86_64-Updates-20180206-1-cryptlvm@uefi.qcow2</a></p>
openQA Tests - action #34471 (New): [qe-core][functional][opensuse][medium] too early matching in...https://progress.opensuse.org/issues/344712018-04-08T06:13:41Zokurzokurz@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario opensuse-42.3-Updates-x86_64-textmode@64bit fails in<br>
<a href="https://openqa.opensuse.org/tests/652064/modules/zypper_up/steps/1" class="external">zypper_up</a></p>
<pre><code>[7 Apr 2018 21:01:23] <tacit> okurz: Somewhat more frequent unstable failure: https://openqa.opensuse.org/tests/652064#step/zypper_up/4 suspecting timing here as the root username is entered before the login promot
[7 Apr 2018 21:57:16] <okurz> tacit: well, problem is the not so good needle in https://openqa.opensuse.org/tests/652064#step/zypper_up/1 . as you can see on the '(i)' icon the test looks for tty6-selected and this is what we should use. What happens now that the test expects tt6, checks for just the generic needle, is happy with tty1, then the VM actually switches to tty6 but in the process the root name is already typed, only after that the getty is
[7 Apr 2018 21:57:16] <okurz> activated. But you know what, I think I have seen this slower behavior even manually. Was there some update to getty or systemd that could have caused a slow down here?
[8 Apr 2018 08:10:09] <okurz> tacit: So actually I would consider a product bug but try to remove our needles nevertheless. We can remove the needle but it might break some tests.
</code></pre>
<a name="Reproducible"></a>
<h2 >Reproducible<a href="#Reproducible" class="wiki-anchor">¶</a></h2>
<p>Fails since (at least) Build <a href="https://openqa.opensuse.org/tests/652064" class="external">20180407-3</a> (current job)</p>
<a name="Expected-result"></a>
<h2 >Expected result<a href="#Expected-result" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC:</strong> There should be no needle with tag "text-login" anymore but only tty$nr-specific ones as we did already for SLE to prevent premature matching</li>
</ul>
<a name="Tasks"></a>
<h2 >Tasks<a href="#Tasks" class="wiki-anchor">¶</a></h2>
<ol>
<li>Remove all needles with tag "text-login"</li>
<li>Fix the tests that use that needle tag.</li>
</ol>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>Find current uses of the generic needles, e.g. "text-login-20160812" using <a href="https://openqa.opensuse.org/admin/needles">https://openqa.opensuse.org/admin/needles</a></li>
<li>Make sure there exist valid tty$nr-selected needles for all cases where text-login is matched on</li>
<li>Delete the too generic needles</li>
<li>Crosscheck carefully that all tests on o3 do not fail because of now deleted needles where there is no tty$nr-replacement.</li>
</ul>
<a name="Further-details"></a>
<h2 >Further details<a href="#Further-details" class="wiki-anchor">¶</a></h2>
<p>Always latest result in this scenario: <a href="https://openqa.opensuse.org/tests/latest?distri=opensuse&machine=64bit&flavor=Updates&test=textmode&version=42.3&arch=x86_64" class="external">latest</a></p>
<p>See <a class="issue tracker-4 status-3 priority-5 priority-high3 closed behind-schedule" title="action: [functional][medium] tty login needles are matched prematurely, username typing gets lost (was: n... (Resolved)" href="https://progress.opensuse.org/issues/33097">#33097</a> for the work that has been done for the corresponding SLE needles.</p>
Travel Support and merchandising mgmt - action #3252 (New): Deadline field for the shipment requestshttps://progress.opensuse.org/issues/32522014-08-22T12:10:13Zancorgsancor@suse.com
<p>The Shipments should have a "deadline" field, since it might happen that the person receiving it has to start travelling early and might need the stuff earlier.</p>