action #15448
closedHole in ths staging process: issues can be missed
100%
Description
Whenever a new kernel comes in to staging, we have a shortcoming in our staging process:
- A new kernel is added to :LETTER
- The kernel, and related packages build
- openQA happens
The main problem we see (again) is that all the rest of the staging is not being rebuilt and MIGHT have a problem with the new kernel RUNNING (e.g. just see with strace: it fails to pass the test suite with 4.8.13 being the running kernel - but this was not spotted during the staging process)
We need a way to guarantee that:
- kernel-obs-build is amongst the first packages to be built
- A full rebuilt of the project is done based on this new kernel
(this makes staging a kernel slower, but it's not the first time we run into this issue and it keeps on popping up)
Updated by dimstar almost 8 years ago
The kernel is actually only one sample of packages that we can miss... (for strace it was red-herring and a co-incidence: 'grep' was the cause)
So this issue expands to everything in VMinstall and preinstall it seems
Updated by dimstar almost 8 years ago
- Subject changed from Kernel staging issue to Hole in ths staging process: issues can be missed
Updated by okurz almost 8 years ago
does the new kernel testing group on openQA help maybe?: https://openqa.opensuse.org/group_overview/32
I don't quite understand what you propose. It is pretty obvious that staging can (by definition) only run a subset of tests so there will be always something missed, isn't it?
Updated by adrian@suse.de almost 8 years ago
On Freitag, 16. Dezember 2016, 07:35:55 CET wrote redmine@opensuse.org:
[openSUSE Tracker]
Issue #15448 has been updated by okurz.does the new kernel testing group on openQA help maybe?: https://openqa.opensuse.org/group_overview/32
I don't quite understand what you propose. It is pretty obvious that staging can (by definition) only run a subset of tests so there will be always something missed, isn't it?
action #15448: Hole in ths staging process: issues can be missed
https://progress.opensuse.org/issues/15448#change-34360
- Author: dimstar
- Status: New
- Priority: Normal
- Assignee: mlin7442
- Category:
* Target version: ¶
Whenever a new kernel comes in to staging, we have a shortcoming in our staging process:
- A new kernel is added to :LETTER
- The kernel, and related packages build
- openQA happens
The main problem we see (again) is that all the rest of the staging is not being rebuilt and MIGHT have a problem with the new kernel RUNNING (e.g. just see with strace: it fails to pass the test suite with 4.8.13 being the running kernel - but this was not spotted during the staging process)
We need a way to guarantee that:
- kernel-obs-build is amongst the first packages to be built
Just declare kernel-obs-build as not supported again.
However, you should only do so in Staging projects using
Suppport: !kernel-obs-build
there
- A full rebuilt of the project is done based on this new kernel
(this makes staging a kernel slower, but it's not the first time we run into this issue and it keeps on popping up)
--
Adrian Schroeter
email: adrian@suse.de
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
Maxfeldstraße 5
90409 Nürnberg
Germany
Updated by adrian@suse.de almost 8 years ago
On Freitag, 16. Dezember 2016, 08:22:22 CET wrote redmine@opensuse.org:
[openSUSE Tracker]
Issue #15448 has been updated by adrian@suse.de.On Freitag, 16. Dezember 2016, 07:35:55 CET wrote redmine@opensuse.org:
[openSUSE Tracker]
Issue #15448 has been updated by okurz.does the new kernel testing group on openQA help maybe?: https://openqa.opensuse.org/group_overview/32
I don't quite understand what you propose. It is pretty obvious that staging can (by definition) only run a subset of tests so there will be always something missed, isn't it?
action #15448: Hole in ths staging process: issues can be missed
https://progress.opensuse.org/issues/15448#change-34360
- Author: dimstar
- Status: New
- Priority: Normal
- Assignee: mlin7442
- Category:
* Target version: ¶
Whenever a new kernel comes in to staging, we have a shortcoming in our staging process:
- A new kernel is added to :LETTER
- The kernel, and related packages build
- openQA happens
The main problem we see (again) is that all the rest of the staging is not being rebuilt and MIGHT have a problem with the new kernel RUNNING (e.g. just see with strace: it fails to pass the test suite with 4.8.13 being the running kernel - but this was not spotted during the staging process)
We need a way to guarantee that:
- kernel-obs-build is amongst the first packages to be built
Just declare kernel-obs-build as not supported again.
this can be misread;) I mean, just remove the "Support" flag
for it. That way the OBS will have it again in build meta data
and will trigger all packages on a change.
However, you should only do so in Staging projects using
Suppport: !kernel-obs-build
there
- A full rebuilt of the project is done based on this new kernel
(this makes staging a kernel slower, but it's not the first time we run into this issue and it keeps on popping up)
--
Adrian Schroeter
email: adrian@suse.de
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
Maxfeldstraße 5
90409 Nürnberg
Germany
Updated by dimstar almost 8 years ago
The kernel is only one example... as I wrote already. Don't get hung up on this. We need a generic approach for the problems
As said: in the previous case for example we missed 'grep' having a regression; as nothing buildrequires grep (and still assumes it's there) - it's a great candidate. Rebuild=direct won't ever catch it (it's part of preinstall)
Updated by mlin7442 over 7 years ago
lnussel wrote:
So we switch to transitive rebuild mode?
well, that would still not good enough for Preinstall and VMinstall, need to check whether the staged request lists in Preinstall or Vminstall, if so waiting new build done and rebuild the others.
Updated by mlin7442 about 7 years ago
- Status changed from In Progress to Resolved
- % Done changed from 0 to 100
Handled by suppkg_rebuild already.