2015-01-26 10:33:26 +00:00
|
|
|
#!/usr/share/openqa/script/load_templates
|
|
|
|
|
#
|
|
|
|
|
# openSUSE Machines, Products, TestSuites and JobTemplates
|
|
|
|
|
#
|
|
|
|
|
# use load_templates to load the file into the database
|
|
|
|
|
#
|
|
|
|
|
{
|
|
|
|
|
JobTemplates => [
|
|
|
|
|
{
|
2015-01-26 13:39:49 +00:00
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 10,
|
2015-01-26 10:33:26 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
2015-01-26 13:39:49 +00:00
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "Workstation-live-iso",
|
2015-03-18 21:28:03 +00:00
|
|
|
version => "*",
|
2015-01-26 10:33:26 +00:00
|
|
|
},
|
2015-03-18 21:28:03 +00:00
|
|
|
test_suite => { name => "default_install" },
|
2015-01-26 10:33:26 +00:00
|
|
|
},
|
2015-09-15 09:04:01 +00:00
|
|
|
{
|
|
|
|
|
machine => { name => "uefi" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 11,
|
2015-09-15 09:04:01 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "Workstation-live-iso",
|
2015-09-15 09:04:01 +00:00
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "default_install" },
|
|
|
|
|
},
|
2015-02-13 09:58:24 +00:00
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 10,
|
2015-02-13 09:58:24 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "Server-boot-iso",
|
2015-03-18 21:28:03 +00:00
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "default_install" },
|
|
|
|
|
},
|
2015-09-15 09:04:01 +00:00
|
|
|
{
|
|
|
|
|
machine => { name => "uefi" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 11,
|
2015-09-15 09:04:01 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "Server-boot-iso",
|
2015-09-15 09:04:01 +00:00
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "default_install" },
|
|
|
|
|
},
|
2015-10-06 22:27:27 +00:00
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 10,
|
2015-10-06 22:27:27 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "Server-dvd-iso",
|
2015-10-06 22:27:27 +00:00
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "default_install" },
|
|
|
|
|
},
|
2015-12-22 08:23:25 +00:00
|
|
|
{
|
|
|
|
|
machine => { name => "uefi" },
|
|
|
|
|
prio => 11,
|
|
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "Server-dvd-iso",
|
2015-12-22 08:23:25 +00:00
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "default_install" },
|
|
|
|
|
},
|
2015-03-18 21:28:03 +00:00
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 10,
|
2015-03-18 21:28:03 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "Everything-boot-iso",
|
2015-03-18 21:28:03 +00:00
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "default_install" },
|
|
|
|
|
},
|
2015-09-15 09:04:01 +00:00
|
|
|
{
|
|
|
|
|
machine => { name => "uefi" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 11,
|
2015-09-15 09:04:01 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "Everything-boot-iso",
|
2015-09-15 09:04:01 +00:00
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "default_install" },
|
|
|
|
|
},
|
2015-09-14 06:52:37 +00:00
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 15,
|
2015-12-22 08:23:25 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "Workstation-boot-iso",
|
2015-12-22 08:23:25 +00:00
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "default_install" },
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
machine => { name => "uefi" },
|
|
|
|
|
prio => 16,
|
|
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "Workstation-boot-iso",
|
2015-12-22 08:23:25 +00:00
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "default_install" },
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
|
|
|
|
prio => 15,
|
|
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "KDE-live-iso",
|
2015-12-22 08:23:25 +00:00
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "default_install" },
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
machine => { name => "uefi" },
|
|
|
|
|
prio => 16,
|
2015-09-14 06:52:37 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "KDE-live-iso",
|
2015-09-14 06:52:37 +00:00
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "default_install" },
|
|
|
|
|
},
|
add a default_install test for cloud atomic installer image
Summary:
We have these 'atomic installer' images (so far just Cloud),
and maxamillion wanted to get them tested. Turns out it's
pretty trivial - they look much like other installs. Only
little wrinkle is they have a reduced hub (no repository
needles) like live images, but are not like live images in
any other way, so I rejigged the 'small hub needle filtering'
handling a bit.
There will be an accompanying diff for tools, and also some
changes in fedfind (these images are getting built nightly
for *current stable*, and it'd be good to test those).
Because we'd like to test the 22 nightlies, I had to add some
needles for 'olddpi' versions of a few screens. See 2e4c1c2 -
the 22 Atomic installer images still have the old GTK+ code
meaning they run at 96.09dpi. I only retook the necessary
needles for the default-install test, if we add any others we
made need to retake a few more needles.
Test Plan:
Schedule jobs for a compose with the atomic installer
image. You will need the matching openqa_fedora_tools diff and
the very latest git fedfind. Check the test for that image runs,
all other tests run as usual, excessive images are not
downloaded, and the atomic installer is not used for running
universal tests.
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D595
2015-09-29 18:36:11 +00:00
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 50,
|
add a default_install test for cloud atomic installer image
Summary:
We have these 'atomic installer' images (so far just Cloud),
and maxamillion wanted to get them tested. Turns out it's
pretty trivial - they look much like other installs. Only
little wrinkle is they have a reduced hub (no repository
needles) like live images, but are not like live images in
any other way, so I rejigged the 'small hub needle filtering'
handling a bit.
There will be an accompanying diff for tools, and also some
changes in fedfind (these images are getting built nightly
for *current stable*, and it'd be good to test those).
Because we'd like to test the 22 nightlies, I had to add some
needles for 'olddpi' versions of a few screens. See 2e4c1c2 -
the 22 Atomic installer images still have the old GTK+ code
meaning they run at 96.09dpi. I only retook the necessary
needles for the default-install test, if we add any others we
made need to retake a few more needles.
Test Plan:
Schedule jobs for a compose with the atomic installer
image. You will need the matching openqa_fedora_tools diff and
the very latest git fedfind. Check the test for that image runs,
all other tests run as usual, excessive images are not
downloaded, and the atomic installer is not used for running
universal tests.
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D595
2015-09-29 18:36:11 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "Cloud_Atomic-boot-iso",
|
add a default_install test for cloud atomic installer image
Summary:
We have these 'atomic installer' images (so far just Cloud),
and maxamillion wanted to get them tested. Turns out it's
pretty trivial - they look much like other installs. Only
little wrinkle is they have a reduced hub (no repository
needles) like live images, but are not like live images in
any other way, so I rejigged the 'small hub needle filtering'
handling a bit.
There will be an accompanying diff for tools, and also some
changes in fedfind (these images are getting built nightly
for *current stable*, and it'd be good to test those).
Because we'd like to test the 22 nightlies, I had to add some
needles for 'olddpi' versions of a few screens. See 2e4c1c2 -
the 22 Atomic installer images still have the old GTK+ code
meaning they run at 96.09dpi. I only retook the necessary
needles for the default-install test, if we add any others we
made need to retake a few more needles.
Test Plan:
Schedule jobs for a compose with the atomic installer
image. You will need the matching openqa_fedora_tools diff and
the very latest git fedfind. Check the test for that image runs,
all other tests run as usual, excessive images are not
downloaded, and the atomic installer is not used for running
universal tests.
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D595
2015-09-29 18:36:11 +00:00
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "default_install" },
|
|
|
|
|
},
|
add a base_selinux test (follow-on from default_install)
Summary:
so here's our first attempt to use the 'carry on from a previous
test' stuff! This adds a base_selinux test that uses a disk
image from a previous default_install run, and adds jobtemplates
to run base_selinux for appropriate products: generic_boot
(for nightly tests), server_dvd, and workstation_live. Note that
you'll want to either update to the newest openQA package I just
built in COPR or create /var/lib/openqa/share/factory/tmp owned
by geekotest; openQA tries to use that directory as MOJO_TMPDIR
but in 4.2, if the directory doesn't exist, it doesn't create it,
and we wind up with the default MOJO_TMPDIR which is /tmp; when
the disk image is uploaded it creates a huge temp file in /tmp
and may well exhaust the available space as it's a tmpfs. I've
backported a recent upstream commit that tries to create the
directory if it doesn't exist, in 4.2-10.
It seems like openQA is smart enough to figure out the
dependencies correctly, so the 'base_selinux' test for each
product depends on the 'default_install' test for the same
product (not any of the other default_install runs) and will
use the hard disk image it produces.
Test Plan:
Do a full test run and make sure base_selinux tests
appear for appropriate products, depend on the correct default_
install test, the default_install test uploads the hard disk
image correctly, and the base_selinux test runs correctly. And
of course that nothing else broke in the process...
Reviewers: jskladan, garretraziel
Reviewed By: jskladan
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D699
2015-12-17 20:46:14 +00:00
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
|
|
|
|
prio => 40,
|
|
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "Everything-boot-iso",
|
add a base_selinux test (follow-on from default_install)
Summary:
so here's our first attempt to use the 'carry on from a previous
test' stuff! This adds a base_selinux test that uses a disk
image from a previous default_install run, and adds jobtemplates
to run base_selinux for appropriate products: generic_boot
(for nightly tests), server_dvd, and workstation_live. Note that
you'll want to either update to the newest openQA package I just
built in COPR or create /var/lib/openqa/share/factory/tmp owned
by geekotest; openQA tries to use that directory as MOJO_TMPDIR
but in 4.2, if the directory doesn't exist, it doesn't create it,
and we wind up with the default MOJO_TMPDIR which is /tmp; when
the disk image is uploaded it creates a huge temp file in /tmp
and may well exhaust the available space as it's a tmpfs. I've
backported a recent upstream commit that tries to create the
directory if it doesn't exist, in 4.2-10.
It seems like openQA is smart enough to figure out the
dependencies correctly, so the 'base_selinux' test for each
product depends on the 'default_install' test for the same
product (not any of the other default_install runs) and will
use the hard disk image it produces.
Test Plan:
Do a full test run and make sure base_selinux tests
appear for appropriate products, depend on the correct default_
install test, the default_install test uploads the hard disk
image correctly, and the base_selinux test runs correctly. And
of course that nothing else broke in the process...
Reviewers: jskladan, garretraziel
Reviewed By: jskladan
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D699
2015-12-17 20:46:14 +00:00
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "base_selinux" },
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
|
|
|
|
prio => 40,
|
|
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "Workstation-live-iso",
|
add a base_selinux test (follow-on from default_install)
Summary:
so here's our first attempt to use the 'carry on from a previous
test' stuff! This adds a base_selinux test that uses a disk
image from a previous default_install run, and adds jobtemplates
to run base_selinux for appropriate products: generic_boot
(for nightly tests), server_dvd, and workstation_live. Note that
you'll want to either update to the newest openQA package I just
built in COPR or create /var/lib/openqa/share/factory/tmp owned
by geekotest; openQA tries to use that directory as MOJO_TMPDIR
but in 4.2, if the directory doesn't exist, it doesn't create it,
and we wind up with the default MOJO_TMPDIR which is /tmp; when
the disk image is uploaded it creates a huge temp file in /tmp
and may well exhaust the available space as it's a tmpfs. I've
backported a recent upstream commit that tries to create the
directory if it doesn't exist, in 4.2-10.
It seems like openQA is smart enough to figure out the
dependencies correctly, so the 'base_selinux' test for each
product depends on the 'default_install' test for the same
product (not any of the other default_install runs) and will
use the hard disk image it produces.
Test Plan:
Do a full test run and make sure base_selinux tests
appear for appropriate products, depend on the correct default_
install test, the default_install test uploads the hard disk
image correctly, and the base_selinux test runs correctly. And
of course that nothing else broke in the process...
Reviewers: jskladan, garretraziel
Reviewed By: jskladan
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D699
2015-12-17 20:46:14 +00:00
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "base_selinux" },
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
|
|
|
|
prio => 40,
|
|
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "Server-dvd-iso",
|
add a base_selinux test (follow-on from default_install)
Summary:
so here's our first attempt to use the 'carry on from a previous
test' stuff! This adds a base_selinux test that uses a disk
image from a previous default_install run, and adds jobtemplates
to run base_selinux for appropriate products: generic_boot
(for nightly tests), server_dvd, and workstation_live. Note that
you'll want to either update to the newest openQA package I just
built in COPR or create /var/lib/openqa/share/factory/tmp owned
by geekotest; openQA tries to use that directory as MOJO_TMPDIR
but in 4.2, if the directory doesn't exist, it doesn't create it,
and we wind up with the default MOJO_TMPDIR which is /tmp; when
the disk image is uploaded it creates a huge temp file in /tmp
and may well exhaust the available space as it's a tmpfs. I've
backported a recent upstream commit that tries to create the
directory if it doesn't exist, in 4.2-10.
It seems like openQA is smart enough to figure out the
dependencies correctly, so the 'base_selinux' test for each
product depends on the 'default_install' test for the same
product (not any of the other default_install runs) and will
use the hard disk image it produces.
Test Plan:
Do a full test run and make sure base_selinux tests
appear for appropriate products, depend on the correct default_
install test, the default_install test uploads the hard disk
image correctly, and the base_selinux test runs correctly. And
of course that nothing else broke in the process...
Reviewers: jskladan, garretraziel
Reviewed By: jskladan
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D699
2015-12-17 20:46:14 +00:00
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "base_selinux" },
|
|
|
|
|
},
|
2016-01-14 18:38:14 +00:00
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
|
|
|
|
prio => 42,
|
|
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "KDE-live-iso",
|
2016-01-14 18:38:14 +00:00
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "base_selinux" },
|
|
|
|
|
},
|
2016-01-08 17:01:33 +00:00
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
|
|
|
|
prio => 40,
|
|
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "Everything-boot-iso",
|
2016-01-08 17:01:33 +00:00
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "base_services_start" },
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
|
|
|
|
prio => 40,
|
|
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "Workstation-live-iso",
|
2016-01-08 17:01:33 +00:00
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "base_services_start" },
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
|
|
|
|
prio => 40,
|
|
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "Server-dvd-iso",
|
2016-01-08 17:01:33 +00:00
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "base_services_start" },
|
|
|
|
|
},
|
2016-01-14 18:38:14 +00:00
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
|
|
|
|
prio => 42,
|
|
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "KDE-live-iso",
|
2016-01-14 18:38:14 +00:00
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "base_services_start" },
|
|
|
|
|
},
|
2016-01-11 20:30:24 +00:00
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
|
|
|
|
prio => 40,
|
|
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "Everything-boot-iso",
|
2016-01-11 20:30:24 +00:00
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "base_service_manipulation" },
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
|
|
|
|
prio => 40,
|
|
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "Workstation-live-iso",
|
2016-01-11 20:30:24 +00:00
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "base_service_manipulation" },
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
|
|
|
|
prio => 40,
|
|
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "Server-dvd-iso",
|
2016-01-11 20:30:24 +00:00
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "base_service_manipulation" },
|
|
|
|
|
},
|
2016-01-14 18:38:14 +00:00
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
|
|
|
|
prio => 42,
|
|
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "KDE-live-iso",
|
2016-01-14 18:38:14 +00:00
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "base_service_manipulation" },
|
|
|
|
|
},
|
2015-03-18 21:28:03 +00:00
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 30,
|
2015-03-18 21:28:03 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
|
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "package_set_minimal" },
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 20,
|
2015-03-18 21:28:03 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
|
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
2015-02-13 09:58:24 +00:00
|
|
|
},
|
|
|
|
|
test_suite => { name => "server_repository_http_variation" },
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 20,
|
2015-02-13 09:58:24 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
2015-03-18 21:28:03 +00:00
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
2015-02-13 09:58:24 +00:00
|
|
|
},
|
|
|
|
|
test_suite => { name => "server_repository_http_graphical" },
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 20,
|
2015-02-13 09:58:24 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
2015-03-18 21:28:03 +00:00
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
2015-02-13 09:58:24 +00:00
|
|
|
},
|
|
|
|
|
test_suite => { name => "server_mirrorlist_graphical" },
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 20,
|
2015-02-13 09:58:24 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
2015-03-18 21:28:03 +00:00
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
2015-02-13 09:58:24 +00:00
|
|
|
},
|
|
|
|
|
test_suite => { name => "server_delete_pata" },
|
|
|
|
|
},
|
2015-09-15 09:04:01 +00:00
|
|
|
{
|
|
|
|
|
machine => { name => "uefi" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 21,
|
2015-09-15 09:04:01 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
|
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "server_delete_pata" },
|
|
|
|
|
},
|
2015-02-13 09:58:24 +00:00
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 20,
|
2015-02-13 09:58:24 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
2015-03-18 21:28:03 +00:00
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
2015-02-13 09:58:24 +00:00
|
|
|
},
|
|
|
|
|
test_suite => { name => "server_kickstart_user_creation" },
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 20,
|
2015-02-13 09:58:24 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
2015-03-18 21:28:03 +00:00
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
2015-02-13 09:58:24 +00:00
|
|
|
},
|
|
|
|
|
test_suite => { name => "server_scsi_updates_img" },
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 20,
|
2015-02-13 09:58:24 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
2015-03-18 21:28:03 +00:00
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
2015-02-13 09:58:24 +00:00
|
|
|
},
|
2016-01-22 20:23:51 +00:00
|
|
|
test_suite => { name => "server_multi" },
|
2015-02-13 09:58:24 +00:00
|
|
|
},
|
2015-09-15 09:04:01 +00:00
|
|
|
{
|
|
|
|
|
machine => { name => "uefi" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 21,
|
2015-09-15 09:04:01 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
|
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
2016-01-22 20:23:51 +00:00
|
|
|
test_suite => { name => "server_multi" },
|
2015-09-15 09:04:01 +00:00
|
|
|
},
|
2015-02-13 09:58:24 +00:00
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 30,
|
2015-02-13 09:58:24 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
2015-03-18 21:28:03 +00:00
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
2015-02-13 09:58:24 +00:00
|
|
|
},
|
|
|
|
|
test_suite => { name => "server_simple_encrypted" },
|
|
|
|
|
},
|
2015-03-05 10:44:02 +00:00
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 30,
|
2015-03-05 10:44:02 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
2015-03-19 21:11:17 +00:00
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
2015-03-05 10:44:02 +00:00
|
|
|
},
|
|
|
|
|
test_suite => { name => "server_simple_free_space" },
|
|
|
|
|
},
|
2015-03-05 12:57:47 +00:00
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 30,
|
2015-03-05 12:57:47 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
2015-03-19 21:11:17 +00:00
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
2015-03-05 12:57:47 +00:00
|
|
|
},
|
|
|
|
|
test_suite => { name => "server_multi_empty" },
|
|
|
|
|
},
|
2015-03-06 09:36:25 +00:00
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 30,
|
2015-03-06 09:36:25 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
2015-03-19 21:11:17 +00:00
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
2015-03-06 09:36:25 +00:00
|
|
|
},
|
|
|
|
|
test_suite => { name => "server_software_raid" },
|
|
|
|
|
},
|
2015-03-12 09:58:04 +00:00
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 30,
|
2015-03-12 09:58:04 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
2015-03-19 21:11:17 +00:00
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
2015-03-12 09:58:04 +00:00
|
|
|
},
|
|
|
|
|
test_suite => { name => "server_delete_partial" },
|
|
|
|
|
},
|
2015-08-10 18:01:12 +00:00
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 40,
|
2015-08-10 18:01:12 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
|
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "server_btrfs" },
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 40,
|
2015-08-10 18:01:12 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
|
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "server_ext3" },
|
|
|
|
|
},
|
2015-11-26 12:50:45 +00:00
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 40,
|
2015-11-26 12:50:45 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
|
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "server_xfs" },
|
|
|
|
|
},
|
2015-08-10 18:01:12 +00:00
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 40,
|
2015-08-10 18:01:12 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
|
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "server_lvmthin" },
|
|
|
|
|
},
|
2015-08-19 21:41:41 +00:00
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 50,
|
2015-08-19 21:41:41 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
|
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "server_no_swap" },
|
|
|
|
|
},
|
2015-12-08 10:49:38 +00:00
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 50,
|
2015-12-08 10:49:38 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
|
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "package_set_kde" },
|
|
|
|
|
},
|
2015-09-15 09:04:01 +00:00
|
|
|
{
|
|
|
|
|
machine => { name => "uefi" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 31,
|
2015-09-15 09:04:01 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
|
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "server_simple_encrypted" },
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
machine => { name => "uefi" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 31,
|
2015-09-15 09:04:01 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
|
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "server_simple_free_space" },
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
machine => { name => "uefi" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 31,
|
2015-09-15 09:04:01 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
|
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "server_multi_empty" },
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
machine => { name => "uefi" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 31,
|
2015-09-15 09:04:01 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
|
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "server_software_raid" },
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
machine => { name => "uefi" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 31,
|
2015-09-15 09:04:01 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
|
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "server_delete_partial" },
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
machine => { name => "uefi" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 41,
|
2015-09-15 09:04:01 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
|
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "server_btrfs" },
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
machine => { name => "uefi" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 41,
|
2015-09-15 09:04:01 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
|
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "server_ext3" },
|
|
|
|
|
},
|
2015-11-26 12:50:45 +00:00
|
|
|
{
|
|
|
|
|
machine => { name => "uefi" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 41,
|
2015-11-26 12:50:45 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
|
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "server_xfs" },
|
|
|
|
|
},
|
2015-09-15 09:04:01 +00:00
|
|
|
{
|
|
|
|
|
machine => { name => "uefi" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 41,
|
2015-09-15 09:04:01 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
|
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "server_lvmthin" },
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
machine => { name => "uefi" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 51,
|
2015-09-15 09:04:01 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
|
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "server_no_swap" },
|
|
|
|
|
},
|
2015-03-12 09:58:04 +00:00
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 30,
|
2015-03-12 09:58:04 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
2015-03-19 21:11:17 +00:00
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
2015-03-12 09:58:04 +00:00
|
|
|
},
|
|
|
|
|
test_suite => { name => "server_kickstart_hdd" },
|
|
|
|
|
},
|
2015-05-13 11:00:46 +00:00
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 30,
|
2015-05-13 11:00:46 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
|
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
convert upgrade tests to dnf-plugin-system-upgrade
Summary:
This is a first cut which more or less works for now. Issues:
1) We're not really testing the BUILD, here. All the test does
is try and upgrade to the specified VERSION - so it'll be using
the latest 'stable' for the given VERSION at the time the test
runs. This isn't really that terrible, but especially for TC/RC
validation, we might want to make things a bit more elaborate
and set up the repo for the actual BUILD (and disable the main
repos).
2) We'd actually need --nogpgcheck for non-Rawhide, at one
specific point in the release cycle - after Branching but
before Bodhi activation (which is when we can be sure all
packages are signed). This won't matter until 24 branches, and
maybe releng will have it fixed by then...if not, I'll tweak
it.
3) We don't really test that the upgrade actually *happened*
for desktop, at the moment - the only thing in the old test
that really checked that was where we checked for the fedup
boot menu entry, but that has no analog in dnf. What we should
probably do is check that GUI login works, then switch to a
console and check /etc/fedora-release just as the minimal test
does.
Test Plan:
Run the tests. Note that creating the desktop disk
image doesn't work ATM, so I can't verify the desktop test
works, but the minimal one seems to (with D565). There'll be
a matching diff for openqa_fedora_tools to update the test
case names there.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D567
2015-09-10 21:49:13 +00:00
|
|
|
test_suite => { name => "upgrade_minimal_64bit" },
|
2015-05-13 11:00:46 +00:00
|
|
|
},
|
2015-07-17 10:52:56 +00:00
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 30,
|
2015-07-17 10:52:56 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
|
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
convert upgrade tests to dnf-plugin-system-upgrade
Summary:
This is a first cut which more or less works for now. Issues:
1) We're not really testing the BUILD, here. All the test does
is try and upgrade to the specified VERSION - so it'll be using
the latest 'stable' for the given VERSION at the time the test
runs. This isn't really that terrible, but especially for TC/RC
validation, we might want to make things a bit more elaborate
and set up the repo for the actual BUILD (and disable the main
repos).
2) We'd actually need --nogpgcheck for non-Rawhide, at one
specific point in the release cycle - after Branching but
before Bodhi activation (which is when we can be sure all
packages are signed). This won't matter until 24 branches, and
maybe releng will have it fixed by then...if not, I'll tweak
it.
3) We don't really test that the upgrade actually *happened*
for desktop, at the moment - the only thing in the old test
that really checked that was where we checked for the fedup
boot menu entry, but that has no analog in dnf. What we should
probably do is check that GUI login works, then switch to a
console and check /etc/fedora-release just as the minimal test
does.
Test Plan:
Run the tests. Note that creating the desktop disk
image doesn't work ATM, so I can't verify the desktop test
works, but the minimal one seems to (with D565). There'll be
a matching diff for openqa_fedora_tools to update the test
case names there.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D567
2015-09-10 21:49:13 +00:00
|
|
|
test_suite => { name => "upgrade_desktop_64bit" },
|
2015-07-17 10:52:56 +00:00
|
|
|
},
|
2015-12-07 17:42:55 +00:00
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 50,
|
2015-12-07 17:42:55 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
|
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "upgrade_2_minimal_64bit" },
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 50,
|
2015-12-07 17:42:55 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
|
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "upgrade_2_desktop_64bit" },
|
|
|
|
|
},
|
2015-08-17 15:36:40 +00:00
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 40,
|
2015-08-17 15:36:40 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
|
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "server_updates_img_local" },
|
|
|
|
|
},
|
2015-09-08 13:54:22 +00:00
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 40,
|
2015-09-08 13:54:22 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
|
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "server_shrink_ext4" },
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 40,
|
2015-09-08 13:54:22 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
|
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "server_shrink_ntfs" },
|
|
|
|
|
},
|
2015-09-15 01:08:58 +00:00
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 40,
|
2015-09-15 01:08:58 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
|
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "european_language_install" },
|
|
|
|
|
},
|
2015-08-16 01:10:14 +00:00
|
|
|
{
|
2015-11-25 11:37:55 +00:00
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 11,
|
2015-08-16 01:10:14 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "i386",
|
|
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "Workstation-live-iso",
|
2015-08-16 01:10:14 +00:00
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "default_install" },
|
|
|
|
|
},
|
|
|
|
|
{
|
2015-11-25 11:37:55 +00:00
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 12,
|
2015-08-16 01:10:14 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "i386",
|
|
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "Server-boot-iso",
|
2015-08-16 01:10:14 +00:00
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "default_install" },
|
|
|
|
|
},
|
2015-10-06 22:27:27 +00:00
|
|
|
{
|
2015-11-25 11:37:55 +00:00
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 12,
|
2015-10-06 22:27:27 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "i386",
|
|
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "Server-dvd-iso",
|
2015-10-06 22:27:27 +00:00
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "default_install" },
|
|
|
|
|
},
|
2015-08-16 01:10:14 +00:00
|
|
|
{
|
2015-11-25 11:37:55 +00:00
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 12,
|
2015-08-16 01:10:14 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "i386",
|
|
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "Everything-boot-iso",
|
2015-08-16 01:10:14 +00:00
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "default_install" },
|
|
|
|
|
},
|
2015-12-22 08:23:25 +00:00
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
|
|
|
|
prio => 17,
|
|
|
|
|
product => {
|
|
|
|
|
arch => "i386",
|
|
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "Workstation-boot-iso",
|
2015-12-22 08:23:25 +00:00
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "default_install" },
|
|
|
|
|
},
|
2015-09-14 06:52:37 +00:00
|
|
|
{
|
2015-11-25 11:37:55 +00:00
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 17,
|
2015-09-14 06:52:37 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "i386",
|
|
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "KDE-live-iso",
|
2015-09-14 06:52:37 +00:00
|
|
|
version => "*",
|
|
|
|
|
},
|
2015-09-15 01:22:05 +00:00
|
|
|
test_suite => { name => "default_install" },
|
2015-09-14 06:52:37 +00:00
|
|
|
},
|
2015-08-16 01:10:14 +00:00
|
|
|
{
|
2015-11-25 11:37:55 +00:00
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 32,
|
2015-08-16 01:10:14 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "i386",
|
|
|
|
|
distri => "fedora",
|
|
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "package_set_minimal" },
|
|
|
|
|
},
|
|
|
|
|
{
|
2015-11-25 11:37:55 +00:00
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 22,
|
2015-08-16 01:10:14 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "i386",
|
|
|
|
|
distri => "fedora",
|
|
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "server_repository_http_graphical" },
|
|
|
|
|
},
|
|
|
|
|
{
|
2015-11-25 11:37:55 +00:00
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 22,
|
2015-08-16 01:10:14 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "i386",
|
|
|
|
|
distri => "fedora",
|
|
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "server_scsi_updates_img" },
|
|
|
|
|
},
|
|
|
|
|
{
|
2015-11-25 11:37:55 +00:00
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 32,
|
2015-08-16 01:10:14 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "i386",
|
|
|
|
|
distri => "fedora",
|
|
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "server_simple_encrypted" },
|
|
|
|
|
},
|
|
|
|
|
{
|
2015-11-25 11:37:55 +00:00
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 32,
|
2015-08-16 01:10:14 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "i386",
|
|
|
|
|
distri => "fedora",
|
|
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "server_software_raid" },
|
|
|
|
|
},
|
|
|
|
|
{
|
2015-11-25 11:37:55 +00:00
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 42,
|
2015-08-16 01:10:14 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "i386",
|
|
|
|
|
distri => "fedora",
|
|
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "server_btrfs" },
|
|
|
|
|
},
|
|
|
|
|
{
|
2015-11-25 11:37:55 +00:00
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 42,
|
2015-08-16 01:10:14 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "i386",
|
|
|
|
|
distri => "fedora",
|
|
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "server_ext3" },
|
|
|
|
|
},
|
|
|
|
|
{
|
2015-11-25 11:37:55 +00:00
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 42,
|
2015-08-16 01:10:14 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "i386",
|
|
|
|
|
distri => "fedora",
|
|
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "server_lvmthin" },
|
|
|
|
|
},
|
|
|
|
|
{
|
2015-11-25 11:37:55 +00:00
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 32,
|
2015-08-16 01:10:14 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "i386",
|
|
|
|
|
distri => "fedora",
|
|
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
convert upgrade tests to dnf-plugin-system-upgrade
Summary:
This is a first cut which more or less works for now. Issues:
1) We're not really testing the BUILD, here. All the test does
is try and upgrade to the specified VERSION - so it'll be using
the latest 'stable' for the given VERSION at the time the test
runs. This isn't really that terrible, but especially for TC/RC
validation, we might want to make things a bit more elaborate
and set up the repo for the actual BUILD (and disable the main
repos).
2) We'd actually need --nogpgcheck for non-Rawhide, at one
specific point in the release cycle - after Branching but
before Bodhi activation (which is when we can be sure all
packages are signed). This won't matter until 24 branches, and
maybe releng will have it fixed by then...if not, I'll tweak
it.
3) We don't really test that the upgrade actually *happened*
for desktop, at the moment - the only thing in the old test
that really checked that was where we checked for the fedup
boot menu entry, but that has no analog in dnf. What we should
probably do is check that GUI login works, then switch to a
console and check /etc/fedora-release just as the minimal test
does.
Test Plan:
Run the tests. Note that creating the desktop disk
image doesn't work ATM, so I can't verify the desktop test
works, but the minimal one seems to (with D565). There'll be
a matching diff for openqa_fedora_tools to update the test
case names there.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D567
2015-09-10 21:49:13 +00:00
|
|
|
test_suite => { name => "upgrade_desktop_32bit" },
|
2015-12-07 18:12:06 +00:00
|
|
|
},
|
2015-12-07 18:10:08 +00:00
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 52,
|
2015-12-07 18:10:08 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "i386",
|
|
|
|
|
distri => "fedora",
|
|
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "upgrade_2_desktop_32bit" },
|
|
|
|
|
},
|
2015-12-08 10:49:38 +00:00
|
|
|
{
|
|
|
|
|
machine => { name => "64bit" },
|
templates: drop 'variables', move 'prio' to JobTemplates
Summary:
this is following a couple of upstream changes I noticeed while
playing with dump_templates. Upstream has completely got rid of
the 'variables' keys from all dicts, and when you run dump_
templates the output does not contain any 'variables' keys, so
it seems reasonable to ditch these entirely (I think it was some
old thing that got subsumed into 'settings'). Also, when you
run dump_templates the 'prio' values come out in JobTemplates,
not in TestSuites; if you look at load_templates there's a bit
marked "we have to migrate the prio from the TestSuite to the
JobTemplate" which does exactly what it sounds like, so it
seems a good idea to move these instead of relying on that to
always be there.
While I had to re-do all the priorities anyway I tried to clean
them up a bit. The idea is roughly this:
10 - 19: most-critical sanity tests (i.e. default_install)
20 - 29: Alpha tests
30 - 39: Beta tests
40 - 49: Final tests
50+ : Optional tests
within each group I ordered 64-bit first, UEFI second, and
32-bit last (usually just as x0 / x1 / x2).
Test Plan:
Check that the file is valid and loads correctly,
and that everything works more or less the same except the
order of tests run is a bit different.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D692
2015-12-16 21:03:41 +00:00
|
|
|
prio => 52,
|
2015-12-08 10:49:38 +00:00
|
|
|
product => {
|
|
|
|
|
arch => "i386",
|
|
|
|
|
distri => "fedora",
|
|
|
|
|
flavor => "universal",
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
test_suite => { name => "package_set_kde" },
|
|
|
|
|
},
|
2015-01-26 10:33:26 +00:00
|
|
|
],
|
|
|
|
|
Machines => [
|
|
|
|
|
{
|
|
|
|
|
backend => "qemu",
|
|
|
|
|
name => "64bit",
|
2015-02-19 13:15:29 +00:00
|
|
|
settings => [
|
2015-11-25 11:37:55 +00:00
|
|
|
{ key => "QEMUCPU", value => "host" },
|
2015-08-16 01:10:14 +00:00
|
|
|
{ key => "QEMUCPUS", value => "2"},
|
2015-11-25 11:37:55 +00:00
|
|
|
{ key => "QEMUVGA", value => "qxl"},
|
2015-10-15 14:07:00 +00:00
|
|
|
{ key => "QEMURAM", value => "2048"},
|
|
|
|
|
{ key => "PART_TABLE_TYPE", value => "mbr"}
|
2015-08-16 01:10:14 +00:00
|
|
|
],
|
|
|
|
|
},
|
2015-09-15 09:04:01 +00:00
|
|
|
{
|
|
|
|
|
backend => "qemu",
|
|
|
|
|
name => "uefi",
|
|
|
|
|
settings => [
|
2015-11-25 11:37:55 +00:00
|
|
|
{ key => "QEMUCPU", value => "host" },
|
2015-09-15 09:04:01 +00:00
|
|
|
{ key => "QEMUCPUS", value => "2"},
|
2015-11-25 11:37:55 +00:00
|
|
|
{ key => "QEMUVGA", value => "qxl"},
|
2015-09-15 09:04:01 +00:00
|
|
|
{ key => "QEMURAM", value => "2048"},
|
2015-10-15 14:07:00 +00:00
|
|
|
{ key => "UEFI", value => "1"},
|
|
|
|
|
{ key => "PART_TABLE_TYPE", value => "gpt"}
|
2015-09-15 09:04:01 +00:00
|
|
|
],
|
|
|
|
|
},
|
2015-01-26 10:33:26 +00:00
|
|
|
],
|
|
|
|
|
Products => [
|
|
|
|
|
{
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
2015-03-18 21:28:03 +00:00
|
|
|
flavor => "universal",
|
|
|
|
|
name => "",
|
|
|
|
|
settings => [
|
|
|
|
|
],
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "Everything-boot-iso",
|
2015-03-18 21:28:03 +00:00
|
|
|
name => "",
|
|
|
|
|
settings => [
|
|
|
|
|
],
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "Server-boot-iso",
|
2015-01-26 10:33:26 +00:00
|
|
|
name => "",
|
|
|
|
|
settings => [
|
|
|
|
|
],
|
2015-03-18 21:28:03 +00:00
|
|
|
version => "*",
|
2015-01-26 10:33:26 +00:00
|
|
|
},
|
2015-10-06 22:27:27 +00:00
|
|
|
{
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "Server-dvd-iso",
|
2015-10-06 22:27:27 +00:00
|
|
|
name => "",
|
|
|
|
|
settings => [
|
|
|
|
|
],
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
add a default_install test for cloud atomic installer image
Summary:
We have these 'atomic installer' images (so far just Cloud),
and maxamillion wanted to get them tested. Turns out it's
pretty trivial - they look much like other installs. Only
little wrinkle is they have a reduced hub (no repository
needles) like live images, but are not like live images in
any other way, so I rejigged the 'small hub needle filtering'
handling a bit.
There will be an accompanying diff for tools, and also some
changes in fedfind (these images are getting built nightly
for *current stable*, and it'd be good to test those).
Because we'd like to test the 22 nightlies, I had to add some
needles for 'olddpi' versions of a few screens. See 2e4c1c2 -
the 22 Atomic installer images still have the old GTK+ code
meaning they run at 96.09dpi. I only retook the necessary
needles for the default-install test, if we add any others we
made need to retake a few more needles.
Test Plan:
Schedule jobs for a compose with the atomic installer
image. You will need the matching openqa_fedora_tools diff and
the very latest git fedfind. Check the test for that image runs,
all other tests run as usual, excessive images are not
downloaded, and the atomic installer is not used for running
universal tests.
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D595
2015-09-29 18:36:11 +00:00
|
|
|
{
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "Cloud_Atomic-boot-iso",
|
add a default_install test for cloud atomic installer image
Summary:
We have these 'atomic installer' images (so far just Cloud),
and maxamillion wanted to get them tested. Turns out it's
pretty trivial - they look much like other installs. Only
little wrinkle is they have a reduced hub (no repository
needles) like live images, but are not like live images in
any other way, so I rejigged the 'small hub needle filtering'
handling a bit.
There will be an accompanying diff for tools, and also some
changes in fedfind (these images are getting built nightly
for *current stable*, and it'd be good to test those).
Because we'd like to test the 22 nightlies, I had to add some
needles for 'olddpi' versions of a few screens. See 2e4c1c2 -
the 22 Atomic installer images still have the old GTK+ code
meaning they run at 96.09dpi. I only retook the necessary
needles for the default-install test, if we add any others we
made need to retake a few more needles.
Test Plan:
Schedule jobs for a compose with the atomic installer
image. You will need the matching openqa_fedora_tools diff and
the very latest git fedfind. Check the test for that image runs,
all other tests run as usual, excessive images are not
downloaded, and the atomic installer is not used for running
universal tests.
Reviewers: jskladan, garretraziel
Reviewed By: garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D595
2015-09-29 18:36:11 +00:00
|
|
|
name => "",
|
|
|
|
|
settings => [
|
|
|
|
|
{ key => "CANNED", value => "1" }
|
|
|
|
|
],
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
2015-12-22 08:23:25 +00:00
|
|
|
{
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "Workstation-boot-iso",
|
2015-12-22 08:23:25 +00:00
|
|
|
name => "",
|
|
|
|
|
settings => [
|
|
|
|
|
{ key => "DESKTOP", value => "gnome" }
|
|
|
|
|
],
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
2015-03-18 21:28:03 +00:00
|
|
|
{
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "Workstation-live-iso",
|
2015-03-18 21:28:03 +00:00
|
|
|
name => "",
|
|
|
|
|
settings => [
|
2015-08-16 01:10:14 +00:00
|
|
|
{ key => "LIVE", value => "1" },
|
|
|
|
|
{ key => "DESKTOP", value => "gnome" }
|
|
|
|
|
],
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
2015-09-14 06:52:37 +00:00
|
|
|
{
|
|
|
|
|
arch => "x86_64",
|
|
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "KDE-live-iso",
|
2015-09-14 06:52:37 +00:00
|
|
|
name => "",
|
|
|
|
|
settings => [
|
|
|
|
|
{ key => "LIVE", value => "1" },
|
|
|
|
|
{ key => "DESKTOP", value => "kde" }
|
|
|
|
|
],
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
2015-08-16 01:10:14 +00:00
|
|
|
{
|
|
|
|
|
arch => "i386",
|
|
|
|
|
distri => "fedora",
|
|
|
|
|
flavor => "universal",
|
|
|
|
|
name => "",
|
|
|
|
|
settings => [
|
|
|
|
|
],
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
arch => "i386",
|
|
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "Everything-boot-iso",
|
2015-08-16 01:10:14 +00:00
|
|
|
name => "",
|
|
|
|
|
settings => [
|
|
|
|
|
],
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
arch => "i386",
|
|
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "Server-boot-iso",
|
2015-08-16 01:10:14 +00:00
|
|
|
name => "",
|
|
|
|
|
settings => [
|
|
|
|
|
],
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
arch => "i386",
|
2015-10-06 22:27:27 +00:00
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "Server-dvd-iso",
|
2015-10-06 22:27:27 +00:00
|
|
|
name => "",
|
|
|
|
|
settings => [
|
|
|
|
|
],
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
2015-12-22 08:23:25 +00:00
|
|
|
{
|
|
|
|
|
arch => "i386",
|
|
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "Workstation-boot-iso",
|
2015-12-22 08:23:25 +00:00
|
|
|
name => "",
|
|
|
|
|
settings => [
|
|
|
|
|
{ key => "DESKTOP", value => "gnome" }
|
|
|
|
|
],
|
|
|
|
|
version => "*",
|
|
|
|
|
},
|
2015-10-06 22:27:27 +00:00
|
|
|
{
|
|
|
|
|
arch => "i386",
|
2015-08-16 01:10:14 +00:00
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "Workstation-live-iso",
|
2015-08-16 01:10:14 +00:00
|
|
|
name => "",
|
|
|
|
|
settings => [
|
2015-03-18 21:28:03 +00:00
|
|
|
{ key => "LIVE", value => "1" },
|
|
|
|
|
{ key => "DESKTOP", value => "gnome" }
|
|
|
|
|
],
|
|
|
|
|
version => "*",
|
2015-09-14 06:52:37 +00:00
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
arch => "i386",
|
|
|
|
|
distri => "fedora",
|
Pungi 4 conversion: handle Pungi-derived BUILD and FLAVOR
With the arrival of Pungi 4, the scheduler is no longer using
fedfind-provided BUILD and FLAVOR values, but ones derived from
Pungi properties. BUILD is now simply the Pungi compose_id.
FLAVOR is produced by joining the Pungi variant, type, and
format with '-' characters as the separators.
Pungi, unfortunately, does not treat 'Rawhide' as a release, it
synthesizes a release number for Rawhide composes and places
that in the compose ID. To cope with that, for now, the
scheduler will set RAWHIDE to '1' if the compose is a Rawhide
one. As we have to adapt all places where we parse the release
in any case, this commit consolidates them into a fedorabase
subroutine.
For the one place where we also used to parse the 'milestone'
from fedfind, there is a placeholder get_milestone subroutine
which currently returns an empty string, as I don't yet have a
good handle on how to draw the kinds of distinctions fedfind
mapped to 'milestone' from Pungi metadata.
2016-01-28 04:48:04 +00:00
|
|
|
flavor => "KDE-live-iso",
|
2015-09-14 06:52:37 +00:00
|
|
|
name => "",
|
|
|
|
|
settings => [
|
|
|
|
|
{ key => "LIVE", value => "1" },
|
|
|
|
|
{ key => "DESKTOP", value => "kde" }
|
|
|
|
|
],
|
|
|
|
|
version => "*",
|
|
|
|
|
}
|
2015-01-26 10:33:26 +00:00
|
|
|
],
|
|
|
|
|
TestSuites => [
|
|
|
|
|
{
|
2015-03-18 21:28:03 +00:00
|
|
|
name => "default_install",
|
|
|
|
|
settings => [
|
|
|
|
|
{ key => "PACKAGE_SET", value => "default" },
|
add a base_selinux test (follow-on from default_install)
Summary:
so here's our first attempt to use the 'carry on from a previous
test' stuff! This adds a base_selinux test that uses a disk
image from a previous default_install run, and adds jobtemplates
to run base_selinux for appropriate products: generic_boot
(for nightly tests), server_dvd, and workstation_live. Note that
you'll want to either update to the newest openQA package I just
built in COPR or create /var/lib/openqa/share/factory/tmp owned
by geekotest; openQA tries to use that directory as MOJO_TMPDIR
but in 4.2, if the directory doesn't exist, it doesn't create it,
and we wind up with the default MOJO_TMPDIR which is /tmp; when
the disk image is uploaded it creates a huge temp file in /tmp
and may well exhaust the available space as it's a tmpfs. I've
backported a recent upstream commit that tries to create the
directory if it doesn't exist, in 4.2-10.
It seems like openQA is smart enough to figure out the
dependencies correctly, so the 'base_selinux' test for each
product depends on the 'default_install' test for the same
product (not any of the other default_install runs) and will
use the hard disk image it produces.
Test Plan:
Do a full test run and make sure base_selinux tests
appear for appropriate products, depend on the correct default_
install test, the default_install test uploads the hard disk
image correctly, and the base_selinux test runs correctly. And
of course that nothing else broke in the process...
Reviewers: jskladan, garretraziel
Reviewed By: jskladan
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D699
2015-12-17 20:46:14 +00:00
|
|
|
{ key => "STORE_HDD_1", value => "disk_%FLAVOR%_%MACHINE%.qcow2" },
|
2015-03-18 21:28:03 +00:00
|
|
|
],
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
name => "package_set_minimal",
|
|
|
|
|
settings => [
|
|
|
|
|
{ key => "PACKAGE_SET", value => "minimal" },
|
|
|
|
|
],
|
2015-01-26 10:33:26 +00:00
|
|
|
},
|
2015-01-26 16:21:32 +00:00
|
|
|
{
|
2016-01-22 20:23:51 +00:00
|
|
|
name => "server_multi",
|
2015-01-26 16:21:32 +00:00
|
|
|
settings => [
|
2015-08-06 09:02:18 +00:00
|
|
|
{ key => "PARTITIONING", value => "guided_multi" },
|
2015-01-27 15:35:10 +00:00
|
|
|
{ key => "NUMDISKS", value => "2" },
|
2015-10-15 14:07:00 +00:00
|
|
|
{ key => "HDD_2", value => "disk_full_mbr.img" },
|
2015-02-13 09:01:38 +00:00
|
|
|
{ key => "ROOT_PASSWORD", value => "weakpassword" },
|
2015-01-27 12:35:27 +00:00
|
|
|
],
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
name => "server_scsi_updates_img",
|
|
|
|
|
settings => [
|
|
|
|
|
{ key => "BOOT_UPDATES_IMG_URL", value => "1" },
|
2015-02-04 13:05:20 +00:00
|
|
|
{ key => "GRUB", value => "inst.updates=https://fedorapeople.org/groups/qa/updates/updates-unipony.img" },
|
2015-01-27 12:35:27 +00:00
|
|
|
{ key => "HDDMODEL", value => "virtio-scsi-pci" },
|
2015-11-09 08:50:24 +00:00
|
|
|
{ key => "CDMODEL", value => "scsi-cd" },
|
2015-01-27 12:35:27 +00:00
|
|
|
],
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
name => "server_kickstart_user_creation",
|
|
|
|
|
settings => [
|
|
|
|
|
{ key => "KICKSTART", value => "1" },
|
2015-02-04 13:05:20 +00:00
|
|
|
{ key => "GRUB", value => "inst.ks=http://jskladan.fedorapeople.org/kickstarts/root-user-crypted-net.ks" },
|
2015-01-27 12:35:27 +00:00
|
|
|
{ key => "USER_LOGIN", value => "test" },
|
|
|
|
|
{ key => "USER_PASSWORD", value => "test" },
|
|
|
|
|
{ key => "ROOT_PASSWORD", value => "111111" },
|
2015-01-26 16:21:32 +00:00
|
|
|
],
|
|
|
|
|
},
|
2015-01-27 13:22:35 +00:00
|
|
|
{
|
|
|
|
|
name => "server_delete_pata",
|
|
|
|
|
settings => [
|
2015-08-06 09:02:18 +00:00
|
|
|
{ key => "PARTITIONING", value => "guided_delete_all" },
|
2015-01-27 13:22:35 +00:00
|
|
|
{ key => "HDDMODEL", value => "ide-hd" },
|
2015-10-15 14:07:00 +00:00
|
|
|
{ key => "HDD_1", value => "disk_full_mbr.img" },
|
2015-01-27 13:22:35 +00:00
|
|
|
],
|
|
|
|
|
},
|
2015-02-04 13:05:20 +00:00
|
|
|
{
|
|
|
|
|
name => "server_mirrorlist_graphical",
|
|
|
|
|
settings => [
|
|
|
|
|
{ key => "MIRRORLIST_GRAPHICAL", value => "1" },
|
|
|
|
|
],
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
name => "server_repository_http_graphical",
|
|
|
|
|
settings => [
|
2015-03-04 11:26:02 +00:00
|
|
|
{ key => "REPOSITORY_GRAPHICAL", value => "http://dl.fedoraproject.org/pub/fedora/linux/development" },
|
2015-02-04 13:05:20 +00:00
|
|
|
],
|
|
|
|
|
},
|
2015-02-04 13:45:37 +00:00
|
|
|
{
|
|
|
|
|
name => "server_repository_http_variation",
|
|
|
|
|
settings => [
|
2015-03-04 11:26:02 +00:00
|
|
|
{ key => "REPOSITORY_VARIATION", value => "http://dl.fedoraproject.org/pub/fedora/linux/development" },
|
2015-02-04 13:45:37 +00:00
|
|
|
],
|
|
|
|
|
},
|
2015-02-13 08:51:24 +00:00
|
|
|
{
|
|
|
|
|
name => "server_delete_partial",
|
|
|
|
|
settings => [
|
2015-08-06 09:02:18 +00:00
|
|
|
{ key => "PARTITIONING", value => "guided_delete_partial" },
|
2015-10-15 14:07:00 +00:00
|
|
|
{ key => "HDD_1", value => "disk_full_%PART_TABLE_TYPE%.img" },
|
2015-02-13 08:51:24 +00:00
|
|
|
{ key => "ROOT_PASSWORD", value => "weakpassword" },
|
|
|
|
|
],
|
|
|
|
|
},
|
2015-02-13 09:58:24 +00:00
|
|
|
{
|
|
|
|
|
name => "server_simple_encrypted",
|
|
|
|
|
settings => [
|
|
|
|
|
{ key => "ENCRYPT_PASSWORD", value => "weakpassword" },
|
|
|
|
|
],
|
|
|
|
|
},
|
2015-03-05 10:44:02 +00:00
|
|
|
{
|
|
|
|
|
name => "server_simple_free_space",
|
|
|
|
|
settings => [
|
2015-08-06 09:02:18 +00:00
|
|
|
{ key => "PARTITIONING", value => "guided_free_space" },
|
2015-10-15 14:07:00 +00:00
|
|
|
{ key => "HDD_1", value => "disk_freespace_%PART_TABLE_TYPE%.img" },
|
2015-03-05 10:44:02 +00:00
|
|
|
{ key => "ROOT_PASSWORD", value => "weakpassword" },
|
|
|
|
|
],
|
|
|
|
|
},
|
2015-03-05 12:57:47 +00:00
|
|
|
{
|
|
|
|
|
name => "server_multi_empty",
|
|
|
|
|
settings => [
|
2015-08-06 09:02:18 +00:00
|
|
|
{ key => "PARTITIONING", value => "guided_multi_empty_all" },
|
2015-03-05 12:57:47 +00:00
|
|
|
{ key => "NUMDISKS", value => "2" },
|
|
|
|
|
{ key => "ROOT_PASSWORD", value => "weakpassword" },
|
|
|
|
|
],
|
|
|
|
|
},
|
2015-03-06 09:36:25 +00:00
|
|
|
{
|
|
|
|
|
name => "server_software_raid",
|
|
|
|
|
settings => [
|
2015-08-06 09:02:18 +00:00
|
|
|
{ key => "PARTITIONING", value => "custom_software_raid" },
|
2015-03-06 09:36:25 +00:00
|
|
|
{ key => "NUMDISKS", value => "2" },
|
|
|
|
|
{ key => "ROOT_PASSWORD", value => "weakpassword" },
|
|
|
|
|
],
|
|
|
|
|
},
|
2015-03-12 09:58:04 +00:00
|
|
|
{
|
2015-08-10 18:01:12 +00:00
|
|
|
name => "server_btrfs",
|
|
|
|
|
settings => [
|
|
|
|
|
{ key => "PARTITIONING", value => "custom_btrfs" },
|
|
|
|
|
{ key => "ROOT_PASSWORD", value => "weakpassword" },
|
|
|
|
|
],
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
name => "server_ext3",
|
|
|
|
|
settings => [
|
|
|
|
|
{ key => "PARTITIONING", value => "custom_ext3" },
|
|
|
|
|
{ key => "ROOT_PASSWORD", value => "weakpassword" },
|
|
|
|
|
],
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
name => "server_lvmthin",
|
|
|
|
|
settings => [
|
|
|
|
|
{ key => "PARTITIONING", value => "custom_lvmthin" },
|
|
|
|
|
{ key => "ROOT_PASSWORD", value => "weakpassword" },
|
|
|
|
|
],
|
|
|
|
|
},
|
|
|
|
|
{
|
2015-08-19 21:41:41 +00:00
|
|
|
name => "server_no_swap",
|
|
|
|
|
settings => [
|
|
|
|
|
{ key => "PARTITIONING", value => "custom_no_swap" },
|
|
|
|
|
{ key => "ROOT_PASSWORD", value => "weakpassword" },
|
|
|
|
|
],
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
name => "server_kickstart_hdd",
|
2015-03-12 09:58:04 +00:00
|
|
|
settings => [
|
|
|
|
|
{ key => "KICKSTART", value => "1" },
|
|
|
|
|
{ key => "GRUB", value => "inst.ks=hd:vdb1:/root-user-crypted-net.ks" },
|
|
|
|
|
{ key => "NUMDISKS", value => "2" },
|
2015-03-12 10:11:47 +00:00
|
|
|
{ key => "HDD_2", value => "disk_ks.img" },
|
2015-03-12 09:58:04 +00:00
|
|
|
{ key => "ROOT_PASSWORD", value => "111111" },
|
|
|
|
|
{ key => "USER_LOGIN", value => "test" },
|
|
|
|
|
{ key => "USER_PASSWORD", value => "test" },
|
|
|
|
|
],
|
|
|
|
|
},
|
2015-05-13 11:00:46 +00:00
|
|
|
{
|
convert upgrade tests to dnf-plugin-system-upgrade
Summary:
This is a first cut which more or less works for now. Issues:
1) We're not really testing the BUILD, here. All the test does
is try and upgrade to the specified VERSION - so it'll be using
the latest 'stable' for the given VERSION at the time the test
runs. This isn't really that terrible, but especially for TC/RC
validation, we might want to make things a bit more elaborate
and set up the repo for the actual BUILD (and disable the main
repos).
2) We'd actually need --nogpgcheck for non-Rawhide, at one
specific point in the release cycle - after Branching but
before Bodhi activation (which is when we can be sure all
packages are signed). This won't matter until 24 branches, and
maybe releng will have it fixed by then...if not, I'll tweak
it.
3) We don't really test that the upgrade actually *happened*
for desktop, at the moment - the only thing in the old test
that really checked that was where we checked for the fedup
boot menu entry, but that has no analog in dnf. What we should
probably do is check that GUI login works, then switch to a
console and check /etc/fedora-release just as the minimal test
does.
Test Plan:
Run the tests. Note that creating the desktop disk
image doesn't work ATM, so I can't verify the desktop test
works, but the minimal one seems to (with D565). There'll be
a matching diff for openqa_fedora_tools to update the test
case names there.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D567
2015-09-10 21:49:13 +00:00
|
|
|
name => "upgrade_minimal_64bit",
|
2015-05-13 11:00:46 +00:00
|
|
|
settings => [
|
|
|
|
|
{ key => "ROOT_PASSWORD", value => "weakpassword" },
|
|
|
|
|
{ key => "BOOTFROM", value => "c" },
|
2015-12-24 20:45:37 +00:00
|
|
|
{ key => "HDD_1", value => "disk_f%CURRREL%_minimal_x86_64.img" },
|
2015-05-13 11:00:46 +00:00
|
|
|
{ key => "UPGRADE", value => "minimal" },
|
|
|
|
|
],
|
|
|
|
|
},
|
2015-07-17 10:52:56 +00:00
|
|
|
{
|
convert upgrade tests to dnf-plugin-system-upgrade
Summary:
This is a first cut which more or less works for now. Issues:
1) We're not really testing the BUILD, here. All the test does
is try and upgrade to the specified VERSION - so it'll be using
the latest 'stable' for the given VERSION at the time the test
runs. This isn't really that terrible, but especially for TC/RC
validation, we might want to make things a bit more elaborate
and set up the repo for the actual BUILD (and disable the main
repos).
2) We'd actually need --nogpgcheck for non-Rawhide, at one
specific point in the release cycle - after Branching but
before Bodhi activation (which is when we can be sure all
packages are signed). This won't matter until 24 branches, and
maybe releng will have it fixed by then...if not, I'll tweak
it.
3) We don't really test that the upgrade actually *happened*
for desktop, at the moment - the only thing in the old test
that really checked that was where we checked for the fedup
boot menu entry, but that has no analog in dnf. What we should
probably do is check that GUI login works, then switch to a
console and check /etc/fedora-release just as the minimal test
does.
Test Plan:
Run the tests. Note that creating the desktop disk
image doesn't work ATM, so I can't verify the desktop test
works, but the minimal one seems to (with D565). There'll be
a matching diff for openqa_fedora_tools to update the test
case names there.
Reviewers: jskladan, garretraziel
Reviewed By: jskladan, garretraziel
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D567
2015-09-10 21:49:13 +00:00
|
|
|
name => "upgrade_desktop_64bit",
|
2015-12-07 17:42:55 +00:00
|
|
|
settings => [
|
|
|
|
|
{ key => "ROOT_PASSWORD", value => "weakpassword" },
|
|
|
|
|
{ key => "BOOTFROM", value => "c" },
|
2015-12-24 20:45:37 +00:00
|
|
|
{ key => "HDD_1", value => "disk_f%CURRREL%_desktop_x86_64.img" },
|
2015-12-07 17:42:55 +00:00
|
|
|
{ key => "UPGRADE", value => "desktop" },
|
2015-12-08 10:49:38 +00:00
|
|
|
{ key => "DESKTOP", value => "gnome" },
|
2015-12-07 17:42:55 +00:00
|
|
|
],
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
name => "upgrade_2_minimal_64bit",
|
|
|
|
|
settings => [
|
|
|
|
|
{ key => "ROOT_PASSWORD", value => "weakpassword" },
|
|
|
|
|
{ key => "BOOTFROM", value => "c" },
|
2015-12-24 20:45:37 +00:00
|
|
|
{ key => "HDD_1", value => "disk_f%PREVREL%_minimal_x86_64.img" },
|
2015-12-07 17:42:55 +00:00
|
|
|
{ key => "UPGRADE", value => "minimal" },
|
|
|
|
|
],
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
name => "upgrade_2_desktop_64bit",
|
2015-07-17 10:52:56 +00:00
|
|
|
settings => [
|
|
|
|
|
{ key => "ROOT_PASSWORD", value => "weakpassword" },
|
|
|
|
|
{ key => "BOOTFROM", value => "c" },
|
2015-12-24 20:45:37 +00:00
|
|
|
{ key => "HDD_1", value => "disk_f%PREVREL%_desktop_x86_64.img" },
|
2015-08-27 11:49:09 +00:00
|
|
|
{ key => "UPGRADE", value => "desktop" },
|
2015-12-08 10:32:48 +00:00
|
|
|
{ key => "DESKTOP", value => "gnome" },
|
2015-08-27 11:49:09 +00:00
|
|
|
],
|
|
|
|
|
},
|
2015-12-07 18:10:08 +00:00
|
|
|
{
|
|
|
|
|
name => "upgrade_desktop_32bit",
|
|
|
|
|
settings => [
|
|
|
|
|
{ key => "ROOT_PASSWORD", value => "weakpassword" },
|
|
|
|
|
{ key => "BOOTFROM", value => "c" },
|
2015-12-24 20:45:37 +00:00
|
|
|
{ key => "HDD_1", value => "disk_f%CURRREL%_desktop_i686.img" },
|
2015-12-07 18:10:08 +00:00
|
|
|
{ key => "UPGRADE", value => "desktop" },
|
2015-12-08 10:49:38 +00:00
|
|
|
{ key => "DESKTOP", value => "gnome" },
|
2015-12-07 18:10:08 +00:00
|
|
|
],
|
|
|
|
|
},
|
2015-08-27 11:49:09 +00:00
|
|
|
{
|
2015-12-07 17:42:55 +00:00
|
|
|
name => "upgrade_2_desktop_32bit",
|
2015-08-27 11:49:09 +00:00
|
|
|
settings => [
|
|
|
|
|
{ key => "ROOT_PASSWORD", value => "weakpassword" },
|
|
|
|
|
{ key => "BOOTFROM", value => "c" },
|
2015-12-24 20:45:37 +00:00
|
|
|
{ key => "HDD_1", value => "disk_f%PREVREL%_desktop_i686.img" },
|
2015-07-17 10:52:56 +00:00
|
|
|
{ key => "UPGRADE", value => "desktop" },
|
2015-12-08 10:32:48 +00:00
|
|
|
{ key => "DESKTOP", value => "gnome" },
|
2015-07-17 10:52:56 +00:00
|
|
|
],
|
|
|
|
|
},
|
2015-08-17 15:36:40 +00:00
|
|
|
{
|
|
|
|
|
name => "server_updates_img_local",
|
|
|
|
|
settings => [
|
|
|
|
|
{ key => "NUMDISKS", value => "2" },
|
|
|
|
|
{ key => "HDD_2", value => "disk_updates_img.img" },
|
|
|
|
|
{ key => "BOOT_UPDATES_IMG_URL", value => "1" },
|
|
|
|
|
{ key => "GRUB", value => "inst.updates=hd:LABEL=UPDATES_IMG:/updates.img" },
|
|
|
|
|
],
|
|
|
|
|
},
|
2015-09-08 13:54:22 +00:00
|
|
|
{
|
|
|
|
|
name => "server_shrink_ext4",
|
|
|
|
|
settings => [
|
|
|
|
|
{ key => "ROOT_PASSWORD", value => "weakpassword" },
|
2015-10-15 14:07:00 +00:00
|
|
|
{ key => "HDD_1", value => "disk_shrink_ext4_mbr.img" },
|
2015-09-08 13:54:22 +00:00
|
|
|
{ key => "PARTITIONING", value => "guided_shrink" },
|
|
|
|
|
],
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
name => "server_shrink_ntfs",
|
|
|
|
|
settings => [
|
|
|
|
|
{ key => "ROOT_PASSWORD", value => "weakpassword" },
|
2015-10-15 14:07:00 +00:00
|
|
|
{ key => "HDD_1", value => "disk_shrink_ntfs_mbr.img" },
|
2015-09-08 13:54:22 +00:00
|
|
|
{ key => "PARTITIONING", value => "guided_shrink" },
|
|
|
|
|
],
|
|
|
|
|
},
|
2015-09-15 01:08:58 +00:00
|
|
|
{
|
|
|
|
|
name => "european_language_install",
|
|
|
|
|
settings => [
|
|
|
|
|
{ key => "LANGUAGE", value => "french" },
|
|
|
|
|
{ key => "USER_LOGIN", value => "qwerty" },
|
|
|
|
|
{ key => "ROOT_PASSWORD", value => "weakpassword" },
|
|
|
|
|
{ key => "ENCRYPT_PASSWORD", value => "weakpassword" },
|
|
|
|
|
],
|
|
|
|
|
},
|
2015-11-26 12:50:45 +00:00
|
|
|
{
|
|
|
|
|
name => "server_xfs",
|
|
|
|
|
settings => [
|
|
|
|
|
{ key => "PARTITIONING", value => "custom_xfs" },
|
|
|
|
|
{ key => "ROOT_PASSWORD", value => "weakpassword" },
|
|
|
|
|
],
|
|
|
|
|
},
|
2015-12-08 10:49:38 +00:00
|
|
|
{
|
|
|
|
|
name => "package_set_kde",
|
|
|
|
|
settings => [
|
|
|
|
|
{ key => "DESKTOP", value => "kde" },
|
|
|
|
|
{ key => "PACKAGE_SET", value => "kde" },
|
|
|
|
|
],
|
|
|
|
|
},
|
add a base_selinux test (follow-on from default_install)
Summary:
so here's our first attempt to use the 'carry on from a previous
test' stuff! This adds a base_selinux test that uses a disk
image from a previous default_install run, and adds jobtemplates
to run base_selinux for appropriate products: generic_boot
(for nightly tests), server_dvd, and workstation_live. Note that
you'll want to either update to the newest openQA package I just
built in COPR or create /var/lib/openqa/share/factory/tmp owned
by geekotest; openQA tries to use that directory as MOJO_TMPDIR
but in 4.2, if the directory doesn't exist, it doesn't create it,
and we wind up with the default MOJO_TMPDIR which is /tmp; when
the disk image is uploaded it creates a huge temp file in /tmp
and may well exhaust the available space as it's a tmpfs. I've
backported a recent upstream commit that tries to create the
directory if it doesn't exist, in 4.2-10.
It seems like openQA is smart enough to figure out the
dependencies correctly, so the 'base_selinux' test for each
product depends on the 'default_install' test for the same
product (not any of the other default_install runs) and will
use the hard disk image it produces.
Test Plan:
Do a full test run and make sure base_selinux tests
appear for appropriate products, depend on the correct default_
install test, the default_install test uploads the hard disk
image correctly, and the base_selinux test runs correctly. And
of course that nothing else broke in the process...
Reviewers: jskladan, garretraziel
Reviewed By: jskladan
Subscribers: tflink
Differential Revision: https://phab.qadevel.cloud.fedoraproject.org/D699
2015-12-17 20:46:14 +00:00
|
|
|
{
|
|
|
|
|
name => "base_selinux",
|
|
|
|
|
settings => [
|
|
|
|
|
{ key => "ENTRYPOINT", value => "base_selinux" },
|
|
|
|
|
{ key => "START_AFTER_TEST", value => "default_install" },
|
|
|
|
|
{ key => "BOOTFROM", value => "c" },
|
|
|
|
|
{ key => "HDD_1", value => "disk_%FLAVOR%_%MACHINE%.qcow2" },
|
|
|
|
|
],
|
|
|
|
|
},
|
2016-01-08 17:01:33 +00:00
|
|
|
{
|
|
|
|
|
name => "base_services_start",
|
|
|
|
|
settings => [
|
|
|
|
|
{ key => "ENTRYPOINT", value => "base_services_start" },
|
|
|
|
|
{ key => "START_AFTER_TEST", value => "default_install" },
|
|
|
|
|
{ key => "BOOTFROM", value => "c" },
|
|
|
|
|
{ key => "HDD_1", value => "disk_%FLAVOR%_%MACHINE%.qcow2" },
|
|
|
|
|
],
|
|
|
|
|
},
|
2016-01-11 20:30:24 +00:00
|
|
|
{
|
|
|
|
|
name => "base_service_manipulation",
|
|
|
|
|
settings => [
|
|
|
|
|
{ key => "ENTRYPOINT", value => "base_service_manipulation" },
|
|
|
|
|
{ key => "START_AFTER_TEST", value => "default_install" },
|
|
|
|
|
{ key => "BOOTFROM", value => "c" },
|
|
|
|
|
{ key => "HDD_1", value => "disk_%FLAVOR%_%MACHINE%.qcow2" },
|
|
|
|
|
],
|
|
|
|
|
},
|
2015-01-26 10:33:26 +00:00
|
|
|
],
|
|
|
|
|
}
|
