Upgrade SLES12SP5 MU released to SLES15SP6 MU unreleased

[chcao]

Add a testsuite to generate the support image of SLES12SP5 via autoyast installation;
Add upgrade autoyast profile and yaml schedule files for migration from maintenance update released to maintenance update unreleased testsuites;
To make the job add target product's maintenance update repos, reset the SCC_ADDONS values because the modules names of SLES12SP5 and SLES15SP5 are different, and there's a blessed modules which would be added during migration fron 12SP5 to 15SPx.

• Related ticket: https://progress.opensuse.org/issues/154951
• Needles: n/a
• Verification run: publish support image; migrate to 15SP6 + MU
• Related mr: https://gitlab.suse.de/qe-yam/openqa-job-groups/-/merge_requests/235

[jknphy]

we should not use old modules like reboot_to_upgrade or version_switch_upgrade_target, check here to inspire you:
https://openqa.suse.de/tests/14698741

[chcao]

we should not use old modules like reboot_to_upgrade or version_switch_upgrade_target, check here to inspire you: https://openqa.suse.de/tests/14698741

Updated, I didn't use version_switch_upgrade_target, this test module switches versions with VERSION_2 settings as target product version. My case should be added to 15SP6 (the target product version), so can not load that new test module.

[jknphy]

please check for libraries not used.

[jknphy]

Please, remove all spaces between lines unless there is clear separation.

[jknphy]

2024

[jknphy]

you don't need conditional logic, you could just get_required_var.
SCC_ADDONS_2 should be explained in the description of this file, so a set_var doesn't require a comment.

[jknphy]

this could go in single line and apparently we don't use OS_TEST_REPOS so it could be initialize it to empty. But I would recommend you something else, have you ever use map in Perl?
You can iterate @addons and then map the hash ref %incidents in a single line without any loop.
https://perldoc.perl.org/functions/map

BUT actually a 3rd option is not to use the existing code from main.pm, we just need a variable with all the repos concatenated, why we don't do that in a loop concatenating each *_TEST_REPOS that we have based in our know addons? would be more simple I guess.

[jknphy]

we don't need this if, we assume that we always have addons, otherwise we could use get_required_var

[jknphy]

mu is not widely used, maintenance updates. It should say `...to a target system using its unreleased maintenance updates'

[jknphy]

There is something peculiar in Perl that you can use to avoid to control so much the values and add conditional code.

Pushing an empty array into an array doesn't create any undef or gaps in the list:

my @maint_test_repo = ('a', 'b', 'c');
push(@maint_test_repo, ());
print Dumper(@maint_test_repo), "\n";

You can try this snippet:

#!/usr/bin/perl
use strict;
use warnings;
use Data::Dumper;

sub get_repo {
  my $addon = shift;
  return "http://repo/with/patch/for/base/1,http://repo/with/patch/for/base/2" if $addon eq "base";
  return "http://repo/with/patch/for/desktop/1" if $addon eq "desktop";
  return "http://repo/with/patch/for/contm/1,http://repo/with/patch/for/contm/2,http://repo/with/patch/for/contm/3 " if $addon eq "contm";
  return "";
}

sub get_addons {
  return "base,serverapp,desktop,sdk,legacy,python3,script,contm,pcm,we";
}

my @maint_test_repo = ();
for my $addon (split(/,/, get_addons())) {
  my @result = split(/,/, get_repo($addon));
  push(@maint_test_repo, split(/,/, get_repo($addon)));
}

print Dumper(@maint_test_repo), "\n";
print join(',', @maint_test_repo);

that means that doing something similar and using the default parameter of get_var it should simplify the code: get_var(uc($addon) . '_TEST_REPOS', "")

Note: zypper in perl-Data-Dump (if you don't have installed in your system)