Hide Forgot
This was not fixed: $ bkr task-list --package coreutils |wc -l 74 $ bkr task-list --package coreutils --non-destructive |wc -l 30 $ bkr task-list --package coreutils --destructive |wc -l 0 And not a single coreutils test is marked as destructive in Makefile... BTW task library on stage does display the destructive flag of a task, production one does not. Is there a bug that tracks this feature?
I wonder, when were the tests with no destructive info last updated? I guess the metadata are filled in only when task is updated and if the value in DB is NULL, the equation would be correct :-/ Should beaker re-read metadata from all tasks when changing DB?
(In reply to comment #2) > I wonder, when were the tests with no destructive info last updated? > around 2011-09-16 > I guess the metadata are filled in only when task is updated and if the value > in DB is NULL, the equation would be correct :-/ > > Should beaker re-read metadata from all tasks when changing DB? That would be great. One question though: Can that be done without changing the "Updated Date" field? That should be reserved for user updates only (we schedule jobs according to that property, mass updates mess things up :)) Also: I've tried to reschedule few of the 'missing' tasks but they didn't appear in the -non-destructive set until I've explicitly added 'Destructive: no" to their Makefiles. This shouldn't be necessary, beaker should treat missing "Destructive" field as 'Destructive: no'.
(In reply to comment #3) > (In reply to comment #2) > > I wonder, when were the tests with no destructive info last updated? > > > around 2011-09-16 > > > I guess the metadata are filled in only when task is updated and if the value > > in DB is NULL, the equation would be correct :-/ And also it looks NULL (in Python None) is the default if nothing is entered. More below. > > > > Should beaker re-read metadata from all tasks when changing DB? > > That would be great. > One question though: Can that be done without changing the "Updated Date" > field? That should be reserved for user updates only (we schedule jobs > according to that property, mass updates mess things up :)) > > Also: I've tried to reschedule few of the 'missing' tasks but they didn't > appear in the -non-destructive set until I've explicitly added 'Destructive: > no" to their Makefiles. This shouldn't be necessary, beaker should treat > missing "Destructive" field as 'Destructive: no'. Should it? The only documentation on "Destructive" flag which says more than 2 words is following: > Aftertest cleanup > > The system have to be in the same state as it was before the test was run. > The only exception is the destructive test. By the same state we do not mean > log files created in desired destination. Source: https://engineering.redhat.com/trac/rhts/wiki/TestPromotingStrategy Would not be safer to consider test destructive (or at least Unknown) until tests author gave it some thought and set non destructiveness explicitly? OTOH beaker-wizard sets this to No by default.
When bug 729257 was fixed, we ran a one-off script to extract the Destructive field from all task's Makefiles. This worked correctly except for a small number of tasks with incorrectly named rpms which the script could not locate. If Destructive is not given in the Makefile we consider the destructiveness to be unknown, rather than assuming one way or the other. Destructiveness will not be shown on the task info page in this case. It's represented internally as None and stored in the database as NULL (as distinct from 0/False or 1/True). In this case the task is neither destructive nor non-destructive, which is why it will appear in `bkr task-list` but not in `bkr task-list --destructive` nor in `bkr task-list --non-destructive`. So I don't think it is a bug that these numbers do not add up. If you need all tests for coreutils to appear in either `bkr task-list --destructive` or `bkr task-list --non-destructive`, please update all of their Makefiles to include the correct value for the Destructive field.
My goal is to be able to identify destructive tests and avoid them during scheduling. Workflows can do this by getting all tests and excluding the destructive ones. So yes, the tristate destructiveness tracking is usable. But it's quite unintuitive. Can you please clearly document it in the usage message for the --destructive and --non-destructive options? Thanks ps: the coreutils tests in question doesn't have destructivity defined because they come from the pre-rhts-wizard times. There's plenty of such tests. And I suspect there are also new tests not generated by beaker-wizard - those will end up with desctructive:undefined too.
Please update the Documentation so this behaviour is understood.
Patch updates the man pages (and hence also online docs), as well as the command line help output http://gerrit.beaker-project.org/#/c/1445/
$ bkr task-list --help | grep destructive --destructive Only include destructive tasks (Note: excludes both non-destructive and unmarked tasks) --non-destructive Only include non-destructive tasks (Note: excludes both destructive and unmarked tasks) Similar wording appears in the man page also.
This has now been released