[opensuse-releaseteam] transactional-update test in openQA
Hi, Looking at the test fail of transactional-update for MicroOS 15.2: https://openqa.opensuse.org/tests/1256193#step/transactional_update/11 So the test has a tarball with ready made rpms that it wants to install. Now this fails on MicroOS 15.2. Turns out that maintenance bumped¹ the version of the update test packages to 5.1 so that's what I have in 15.2. Wheres that tarball was built with Factory packages that have version 5. The version doesn't really matter for the Tumbleweed tests as the update-test packages are not installed by default there. Stable distros do have them by default though during beta test. So calling zypper in on a package with lower version will not do anything. Of course we could version bump the package in Factory, rebuild the tarball and have newer version rpms. I fear that this would just work temporarily though until release numbers increase. So how about changing the test to not use a tarball but install from the repo instead, ie just calling transactional-update with package name rather than filename? Looks like even Factory has the update test packages in the :Update repo. So should work, right? cu Ludwig [1] bug 1070228, I already asked to apply the change to Factory too -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, HRB 36809 (AG Nürnberg), GF: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-releaseteam+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-releaseteam+owner@opensuse.org
Hi, Am Mittwoch, 6. Mai 2020, 10:13:36 CEST schrieb Ludwig Nussel:
Hi,
Looking at the test fail of transactional-update for MicroOS 15.2: https://openqa.opensuse.org/tests/1256193#step/transactional_update/11
So the test has a tarball with ready made rpms that it wants to install. Now this fails on MicroOS 15.2. Turns out that maintenance bumped¹ the version of the update test packages to 5.1 so that's what I have in 15.2. Wheres that tarball was built with Factory packages that have version 5. The version doesn't really matter for the Tumbleweed tests as the update-test packages are not installed by default there. Stable distros do have them by default though during beta test. So calling zypper in on a package with lower version will not do anything.
I fell into that trap as well when I first looked at the t-u test module in openQA. It's actually meant to work like this: 1. Install the manually created update-test-security rpm using t-u ptf, reboot 2. Run t-u up to update the update-test-security package to the version in the update repo For this, the packages in the repo have to be newer than the ones in the tarball. In this case, the failure is simply because the update-test-* packages are already installed, which is not the case on TW MicroOS. So the way to fix it is to simply not install the update-test-* packages on MicroOS 15.2 before the t-u test module. Proof: https://openqa.opensuse.org/tests/1255792#step/transactional_update/12 The following NEW package is going to be installed: update-test-security Cheers, Fabian
Of course we could version bump the package in Factory, rebuild the tarball and have newer version rpms. I fear that this would just work temporarily though until release numbers increase.
So how about changing the test to not use a tarball but install from the repo instead, ie just calling transactional-update with package name rather than filename? Looks like even Factory has the update test packages in the :Update repo. So should work, right?
cu Ludwig
[1] bug 1070228, I already asked to apply the change to Factory too
-- To unsubscribe, e-mail: opensuse-releaseteam+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-releaseteam+owner@opensuse.org
Am 06.05.20 um 10:23 schrieb Fabian Vogt:
Am Mittwoch, 6. Mai 2020, 10:13:36 CEST schrieb Ludwig Nussel:
Looking at the test fail of transactional-update for MicroOS 15.2: https://openqa.opensuse.org/tests/1256193#step/transactional_update/11
So the test has a tarball with ready made rpms that it wants to install. Now this fails on MicroOS 15.2. Turns out that maintenance bumped¹ the version of the update test packages to 5.1 so that's what I have in 15.2. Wheres that tarball was built with Factory packages that have version 5. The version doesn't really matter for the Tumbleweed tests as the update-test packages are not installed by default there. Stable distros do have them by default though during beta test. So calling zypper in on a package with lower version will not do anything.
I fell into that trap as well when I first looked at the t-u test module in openQA. It's actually meant to work like this:
1. Install the manually created update-test-security rpm using t-u ptf, reboot 2. Run t-u up to update the update-test-security package to the version in the update repo
For this, the packages in the repo have to be newer than the ones in the tarball. In this case, the failure is simply because the update-test-* packages are already installed, which is not the case on TW MicroOS. So the way to fix it is to simply not install the update-test-* packages on MicroOS 15.2 before the t-u test module.
Ok that would work but is inconsistent with how the main distro works. The whole point of those update-test packages is that they are there and the update stack triggers on them due to availability updates for them. AFAICS the test could just do that actually. The step 1) you outlined only needs to be applied when BETA=1 is not set. If the call is changed to install from the oss repo, step 2) would still work as is. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, HRB 36809 (AG Nürnberg), GF: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-releaseteam+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-releaseteam+owner@opensuse.org
Hi, Am Mittwoch, 6. Mai 2020, 10:30:20 CEST schrieb Ludwig Nussel:
Am 06.05.20 um 10:23 schrieb Fabian Vogt:
Am Mittwoch, 6. Mai 2020, 10:13:36 CEST schrieb Ludwig Nussel:
Looking at the test fail of transactional-update for MicroOS 15.2: https://openqa.opensuse.org/tests/1256193#step/transactional_update/11
So the test has a tarball with ready made rpms that it wants to install. Now this fails on MicroOS 15.2. Turns out that maintenance bumped¹ the version of the update test packages to 5.1 so that's what I have in 15.2. Wheres that tarball was built with Factory packages that have version 5. The version doesn't really matter for the Tumbleweed tests as the update-test packages are not installed by default there. Stable distros do have them by default though during beta test. So calling zypper in on a package with lower version will not do anything.
I fell into that trap as well when I first looked at the t-u test module in openQA. It's actually meant to work like this:
1. Install the manually created update-test-security rpm using t-u ptf, reboot 2. Run t-u up to update the update-test-security package to the version in the update repo
For this, the packages in the repo have to be newer than the ones in the tarball. In this case, the failure is simply because the update-test-* packages are already installed, which is not the case on TW MicroOS. So the way to fix it is to simply not install the update-test-* packages on MicroOS 15.2 before the t-u test module.
Ok that would work but is inconsistent with how the main distro works. The whole point of those update-test packages is that they are there and the update stack triggers on them due to availability updates for them.
AFAICS the test could just do that actually. The step 1) you outlined only needs to be applied when BETA=1 is not set. If the call is changed to install from the oss repo, step 2) would still work as is.
To avoid having two different code paths for pre-release and post-release testing, I would just do a minimal fix to allow installation of the rpm despite the lower version. Not sure whether t-u ptf allows downgrades though. Cheers, Fabian
cu Ludwig
-- To unsubscribe, e-mail: opensuse-releaseteam+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-releaseteam+owner@opensuse.org
Am 06.05.20 um 12:09 schrieb Fabian Vogt:
Hi,
Am Mittwoch, 6. Mai 2020, 10:30:20 CEST schrieb Ludwig Nussel:
Am 06.05.20 um 10:23 schrieb Fabian Vogt:
Am Mittwoch, 6. Mai 2020, 10:13:36 CEST schrieb Ludwig Nussel:
Looking at the test fail of transactional-update for MicroOS 15.2: https://openqa.opensuse.org/tests/1256193#step/transactional_update/11
So the test has a tarball with ready made rpms that it wants to install. Now this fails on MicroOS 15.2. Turns out that maintenance bumped¹ the version of the update test packages to 5.1 so that's what I have in 15.2. Wheres that tarball was built with Factory packages that have version 5. The version doesn't really matter for the Tumbleweed tests as the update-test packages are not installed by default there. Stable distros do have them by default though during beta test. So calling zypper in on a package with lower version will not do anything.
I fell into that trap as well when I first looked at the t-u test module in openQA. It's actually meant to work like this:
1. Install the manually created update-test-security rpm using t-u ptf, reboot 2. Run t-u up to update the update-test-security package to the version in the update repo
For this, the packages in the repo have to be newer than the ones in the tarball. In this case, the failure is simply because the update-test-* packages are already installed, which is not the case on TW MicroOS. So the way to fix it is to simply not install the update-test-* packages on MicroOS 15.2 before the t-u test module.
Ok that would work but is inconsistent with how the main distro works. The whole point of those update-test packages is that they are there and the update stack triggers on them due to availability updates for them.
AFAICS the test could just do that actually. The step 1) you outlined only needs to be applied when BETA=1 is not set. If the call is changed to install from the oss repo, step 2) would still work as is.
To avoid having two different code paths for pre-release and post-release testing, I would just do a minimal fix to allow installation of the rpm despite the lower version. Not sure whether t-u ptf allows downgrades though.
Argh, there actually is a code path that checks for BETA. It removes the update-test package and then reboot. It just also checks for is_leap so that's why it doesn't work for microos... cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, HRB 36809 (AG Nürnberg), GF: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-releaseteam+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-releaseteam+owner@opensuse.org
participants (2)
-
Fabian Vogt -
Ludwig Nussel