openQA Project (public) » openQA Tests (public)

When creating the schedules, put them in schedule/alp, although they are using main.pm

PR: https://github.com/os-autoinst/opensuse-jobgroups/pull/197
YAML_SCHEDULE: https://github.com/os-autoinst/opensuse-jobgroups/pull/197

https://github.com/os-autoinst/opensuse-jobgroups/pull/197/ PR for adding database tests on ALP.

szarate wrote:

Zaoliang, Dee... What's left on this ticket? iirc enabling the transactional flavors, right?

the problem is https://github.com/os-autoinst/opensuse-jobgroups/pull/201
What I did in my PR, has been dropped by new job group.
Let's think about this change and make an update??

my try: http://10.162.30.85/tests/5041#step/sqlite3/19

even I add standard repository from ALP, it could work because zypper exit code 5. kvm image is read-only. Non-transactional image is not provided at moment.

On 22. 9. 2022, at 11:13, redmine@opensuse.org wrote:

even I add standard repository from ALP, it could work because zypper exit code 5. kvm image is read-only. Non-transactional image is not provided at moment.

And you do use /sbin/transactional-update right?

yes, I tried this but this is not working:

http://10.162.30.85/tests/5049#step/sqlite3

Info about transactional-update:
https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-transactional-updates.html

Only packages that are part of the snapshot of the root file system can be updated. If packages contain files that are not part of the snapshot, the update could fail or break the system.

I don’t understand. Can you include some command line output?

pdostal wrote:

I don’t understand. Can you include some command line output?

I tried this:

if(check_var('DISTRI', 'alp')) {
        assert_script_run('transactional-update pkg install sqlite3 expect perl');
     } 
     else {
        zypper_call('install sqlite3 expect perl');
     }

Test died: command 'transactional-update pkg install sqlite3 expect perl' timed out at alp/tests/console/sqlite3.pm line 28.

Then maybe try this:

if (is_transactional) {
trup_call('pkg install     
check_reboot_changes;
} else {
zypper_call('in firewalld');
}

pdostal wrote:

Then maybe try this:

if (is_transactional) {
trup_call('pkg install     
check_reboot_changes;
} else {
zypper_call('in firewalld');
}

no, this is not working for trup_call or trup_install:
http://10.162.30.85/tests/5054#step/sqlite3/11

Test died: Confirmation dialog not shown at alp/lib/transactional.pm line 177.

Then it's in my opinion a bug in trup_call which should be fixed.

pdostal wrote:

Then it's in my opinion a bug in trup_call which should be fixed.

indeed, one idea that comes to mind, is to make turp to switch to root console and then switch back to whatever was before... but it's a hack... There's https://progress.opensuse.org/issues/117028

However, for now... if if it's a transactional system, use root-console instead of serial console.

The transactional systems (including ALP) we should use subroutines from lib/transactional.pm.
That basically means that if installing packages on ALP is broken we should fix it in lib/transactional.pm.

I called the trup_call function in the root console, this seems to be working fine. Verification run after switching to the root console - sqlite3