srbala/os-autoinst-distri-fedora
1
0
Fork 0
mirror of https://pagure.io/fedora-qa/os-autoinst-distri-fedora.git synced 2024-11-24 14:53:09 +00:00
Code Issues Releases Activity
18edc46417
os-autoinst-distri-fedora/templates.fif.json

3248 lines
133 KiB
JSON
Raw Normal View History

Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
{
"Machines": {
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"bios": {
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"backend": "qemu",
"settings": {
"ARCH_BASE_MACHINE": "64bit",
"PART_TABLE_TYPE": "mbr",
"QEMUCPU": "Nehalem",
"QEMUCPUS": "2",
Bump RAM on x86_64 machines to 3G Workstation tests on Rawhide are getting OOM killed. Let's see if this helps. All the other arches have this much already, and the worker hosts can handle it. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-08-18 17:41:13 +00:00
"QEMURAM": "3072",
Replace QEMUVGA with QEMU_VIDEO_DEVICE
2023-02-27 17:02:09 +00:00
"QEMU_VIDEO_DEVICE": "virtio-vga",
Increase QEMU_MAX_MIGRATION_TIME to avoid incomplete tests We see tests periodically come up incomplete with this: "Migrate to file failed, it has been running for more than 240 seconds" Turns out there's a setting for this, so...let's set it. I don't think there's really a bug here, just when our workers are busy, these migrations can take longer than expected. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-10-12 08:35:02 +00:00
"QEMU_MAX_MIGRATION_TIME": "480",
"QEMU_VIRTIO_RNG": "1",
Create a test case for Archiver.
2022-09-12 07:38:09 +00:00
"XRES": "1024",
"YRES": "768",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"WORKER_CLASS": "qemu_x86_64"
}
},
"aarch64": {
"backend": "qemu",
"settings": {
"ARCH_BASE_MACHINE": "aarch64",
"PART_TABLE_TYPE": "gpt",
"QEMU": "aarch64",
"QEMUCPU": "host",
"QEMUCPUS": "2",
Set gic-version=max for aarch64 qemu 'machine' arg This is needed for qemu to run on the new aarch64 worker hosts, per https://bugzilla.redhat.com/show_bug.cgi?id=1661976 . Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-03-04 00:41:04 +00:00
"QEMUMACHINE": "virt,gic-version=max",
Try giving aarch64 VMs more RAM to see if it helps desktop tests are very very fail-y on aarch64, with all kinds of random failure cases. I suspect the worker hosts are just *slow*, but they do have plenty of RAM per worker instance, so let's try throwing a bit more RAM at each one and see if that helps at all. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-05 16:05:32 +00:00
"QEMURAM": 4096,
Increase QEMU_MAX_MIGRATION_TIME to avoid incomplete tests We see tests periodically come up incomplete with this: "Migrate to file failed, it has been running for more than 240 seconds" Turns out there's a setting for this, so...let's set it. I don't think there's really a bug here, just when our workers are busy, these migrations can take longer than expected. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-10-12 08:35:02 +00:00
"QEMU_MAX_MIGRATION_TIME": "480",
Replace QEMUVGA with QEMU_VIDEO_DEVICE
2023-02-27 17:02:09 +00:00
"QEMU_VIDEO_DEVICE": "virtio-gpu-pci",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"QEMU_VIRTIO_RNG": "1",
"SERIALDEV": "ttyAMA0",
"TIMEOUT_SCALE": "1.5",
"UEFI": "1",
"UEFI_PFLASH_CODE": "/usr/share/edk2/aarch64/QEMU_EFI-pflash.raw",
"UEFI_PFLASH_VARS": "/usr/share/edk2/aarch64/vars-template-pflash.raw",
"WORKER_CLASS": "qemu_aarch64"
}
},
"ppc64le": {
"backend": "qemu",
"settings": {
"ARCH_BASE_MACHINE": "ppc64le",
"OFW": 1,
"PART_TABLE_TYPE": "mbr",
"QEMU": "ppc64",
"QEMUCPU": "host",
"QEMURAM": 4096,
Replace QEMUVGA with QEMU_VIDEO_DEVICE
2023-02-27 17:02:09 +00:00
"QEMU_VIDEO_DEVICE": "VGA",
Increase QEMU_MAX_MIGRATION_TIME to avoid incomplete tests We see tests periodically come up incomplete with this: "Migrate to file failed, it has been running for more than 240 seconds" Turns out there's a setting for this, so...let's set it. I don't think there's really a bug here, just when our workers are busy, these migrations can take longer than expected. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-10-12 08:35:02 +00:00
"QEMU_MAX_MIGRATION_TIME": "480",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"QEMU_VIRTIO_RNG": "1",
"WORKER_CLASS": "qemu_ppc64le"
}
},
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"64bit": {
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"backend": "qemu",
"settings": {
"ARCH_BASE_MACHINE": "64bit",
"PART_TABLE_TYPE": "gpt",
"QEMUCPU": "Nehalem",
"QEMUCPUS": "2",
Bump RAM on x86_64 machines to 3G Workstation tests on Rawhide are getting OOM killed. Let's see if this helps. All the other arches have this much already, and the worker hosts can handle it. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-08-18 17:41:13 +00:00
"QEMURAM": "3072",
Replace QEMUVGA with QEMU_VIDEO_DEVICE
2023-02-27 17:02:09 +00:00
"QEMU_VIDEO_DEVICE": "virtio-vga",
Create a test case for Archiver.
2022-09-12 07:38:09 +00:00
"XRES": "1024",
"YRES": "768",
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"QEMUMACHINE": "q35,smm=on",
"QEMU_APPEND": "global driver=cfi.pflash01,property=secure,value=on",
Increase QEMU_MAX_MIGRATION_TIME to avoid incomplete tests We see tests periodically come up incomplete with this: "Migrate to file failed, it has been running for more than 240 seconds" Turns out there's a setting for this, so...let's set it. I don't think there's really a bug here, just when our workers are busy, these migrations can take longer than expected. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-10-12 08:35:02 +00:00
"QEMU_MAX_MIGRATION_TIME": "480",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"QEMU_VIRTIO_RNG": "1",
"UEFI": "1",
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"UEFI_PFLASH_CODE": "/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd",
"UEFI_PFLASH_VARS": "/usr/share/edk2/ovmf/OVMF_VARS.secboot.fd",
"UEFI_SECURE": "1",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"WORKER_CLASS": "qemu_x86_64"
}
}
},
"Products": {
Add initial template stuff and test tweaks for ELN testing Just a couple of flavors and tests for now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-06-19 14:01:39 +00:00
"fedora-BaseOS-boot-iso-x86_64-*": {
"arch": "x86_64",
"distri": "fedora",
"flavor": "BaseOS-boot-iso",
"settings": {
"DEPLOY_UPLOAD_TEST": "install_default_upload",
"+QEMUCPU": "Haswell",
"TEST_TARGET": "ISO"
},
"version": "*"
},
"fedora-BaseOS-dvd-iso-x86_64-*": {
"arch": "x86_64",
"distri": "fedora",
"flavor": "BaseOS-dvd-iso",
"settings": {
"DEPLOY_UPLOAD_TEST": "install_default_upload",
"+QEMUCPU": "Haswell",
"TEST_TARGET": "ISO"
},
"version": "*"
},
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"fedora-Cloud_Base-qcow2-qcow2-aarch64-*": {
"arch": "aarch64",
"distri": "fedora",
"flavor": "Cloud_Base-qcow2-qcow2",
"settings": {
"BOOTFROM": "c",
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"DEPLOY_UPLOAD_TEST": "",
Fix Cloud tests to run on correct image For Cloud, we want to run these tests directly on the disk image from the compose. But for other flavors, they are run on a disk image produced by install_default_upload, so the test suites specify HDD_1. This causes a problem as the value from the test suite is used as the filename when downloading the image, but that file name does not change between composes, so instead of downloading the image to be tested for each compose, we just wound up downloading it one time and then re-using that same file every day. Solving this is a bit tricky for reasons explained in the fedora_openqa commit, but this is the best option I could think of. The scheduler has been changed to schedule the downloaded image as HDD_2_URL, not HDD_1_URL; so now in the templates we just override the HDD_1 value for the Cloud flavors to "%HDD_2%", meaning to take the value of HDD_2 (which will be parsed from HDD_2_URL). We do not actually attach HDD_2 at all, it's only used to be copied to HDD_1. We also explicitly set DEPLOY_UPLOAD_TEST to "" for all flavors (it was only set for one before), just for clarity. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2021-05-19 19:27:52 +00:00
"+HDD_1": "%HDD_2%",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"ISO": "cloudinit.iso",
"ROOT_PASSWORD": "weakpassword",
"TEST_TARGET": "HDD_1"
},
"version": "*"
},
"fedora-Cloud_Base-qcow2-qcow2-ppc64le-*": {
"arch": "ppc64le",
"distri": "fedora",
"flavor": "Cloud_Base-qcow2-qcow2",
"settings": {
"BOOTFROM": "c",
Fix Cloud tests to run on correct image For Cloud, we want to run these tests directly on the disk image from the compose. But for other flavors, they are run on a disk image produced by install_default_upload, so the test suites specify HDD_1. This causes a problem as the value from the test suite is used as the filename when downloading the image, but that file name does not change between composes, so instead of downloading the image to be tested for each compose, we just wound up downloading it one time and then re-using that same file every day. Solving this is a bit tricky for reasons explained in the fedora_openqa commit, but this is the best option I could think of. The scheduler has been changed to schedule the downloaded image as HDD_2_URL, not HDD_1_URL; so now in the templates we just override the HDD_1 value for the Cloud flavors to "%HDD_2%", meaning to take the value of HDD_2 (which will be parsed from HDD_2_URL). We do not actually attach HDD_2 at all, it's only used to be copied to HDD_1. We also explicitly set DEPLOY_UPLOAD_TEST to "" for all flavors (it was only set for one before), just for clarity. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2021-05-19 19:27:52 +00:00
"DEPLOY_UPLOAD_TEST": "",
"+HDD_1": "%HDD_2%",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"ISO": "cloudinit.iso",
"ROOT_PASSWORD": "weakpassword",
"TEST_TARGET": "HDD_1"
},
"version": "*"
},
"fedora-Cloud_Base-qcow2-qcow2-x86_64-*": {
"arch": "x86_64",
"distri": "fedora",
"flavor": "Cloud_Base-qcow2-qcow2",
"settings": {
"BOOTFROM": "c",
Fix Cloud tests to run on correct image For Cloud, we want to run these tests directly on the disk image from the compose. But for other flavors, they are run on a disk image produced by install_default_upload, so the test suites specify HDD_1. This causes a problem as the value from the test suite is used as the filename when downloading the image, but that file name does not change between composes, so instead of downloading the image to be tested for each compose, we just wound up downloading it one time and then re-using that same file every day. Solving this is a bit tricky for reasons explained in the fedora_openqa commit, but this is the best option I could think of. The scheduler has been changed to schedule the downloaded image as HDD_2_URL, not HDD_1_URL; so now in the templates we just override the HDD_1 value for the Cloud flavors to "%HDD_2%", meaning to take the value of HDD_2 (which will be parsed from HDD_2_URL). We do not actually attach HDD_2 at all, it's only used to be copied to HDD_1. We also explicitly set DEPLOY_UPLOAD_TEST to "" for all flavors (it was only set for one before), just for clarity. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2021-05-19 19:27:52 +00:00
"DEPLOY_UPLOAD_TEST": "",
"+HDD_1": "%HDD_2%",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"ISO": "cloudinit.iso",
"ROOT_PASSWORD": "weakpassword",
"TEST_TARGET": "HDD_1"
},
"version": "*"
},
Add initial CoreOS product and test templates Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-08-19 21:58:02 +00:00
"fedora-CoreOS-colive-iso-x86_64-*": {
"arch": "x86_64",
"distri": "fedora",
"flavor": "CoreOS-colive-iso",
"settings": {
"CANNED": "1",
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"DEPLOY_UPLOAD_TEST": "install_default_upload",
Add initial CoreOS product and test templates Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-08-19 21:58:02 +00:00
"TEST_TARGET": "ISO",
"USER_LOGIN": "false"
},
"version": "*"
},
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"fedora-Everything-boot-iso-ppc64le-*": {
"arch": "ppc64le",
"distri": "fedora",
"flavor": "Everything-boot-iso",
"settings": {
"TEST_TARGET": "ISO"
},
"version": "*"
},
"fedora-Everything-boot-iso-x86_64-*": {
"arch": "x86_64",
"distri": "fedora",
"flavor": "Everything-boot-iso",
"settings": {
Try harder to apply that 3GiB RAM setting Seems it may need the magic override... Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-07-17 19:44:54 +00:00
"+QEMURAM": 3072,
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"TEST_TARGET": "ISO"
},
"version": "*"
},
Enable IoT testing with install and base tests IoT is becoming a release-blocking edition for F32, so we should be testing it for sure. We may add specific tests, but for now let's run the install and base tests on it. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-02-13 19:50:32 +00:00
"fedora-IoT-dvd_ostree-iso-aarch64-*": {
"arch": "aarch64",
"distri": "fedora",
"flavor": "IoT-dvd_ostree-iso",
"settings": {
"CANNED": "1",
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"DEPLOY_UPLOAD_TEST": "install_default_upload",
Enable IoT testing with install and base tests IoT is becoming a release-blocking edition for F32, so we should be testing it for sure. We may add specific tests, but for now let's run the install and base tests on it. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-02-13 19:50:32 +00:00
"PACKAGE_SET": "default",
"TEST_TARGET": "ISO"
},
"version": "*"
},
"fedora-IoT-dvd_ostree-iso-x86_64-*": {
"arch": "x86_64",
"distri": "fedora",
"flavor": "IoT-dvd_ostree-iso",
"settings": {
"CANNED": "1",
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"DEPLOY_UPLOAD_TEST": "install_default_upload",
Enable IoT testing with install and base tests IoT is becoming a release-blocking edition for F32, so we should be testing it for sure. We may add specific tests, but for now let's run the install and base tests on it. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-02-13 19:50:32 +00:00
"PACKAGE_SET": "default",
"TEST_TARGET": "ISO"
},
"version": "*"
},
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"fedora-KDE-live-iso-x86_64-*": {
"arch": "x86_64",
"distri": "fedora",
"flavor": "KDE-live-iso",
"settings": {
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"DEPLOY_UPLOAD_TEST": "install_default_upload",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"DESKTOP": "kde",
Bump HDDSIZEGB for more GNOME and KDE products We have it at 20G for Workstation live, but not for KDE live or for the update Workstation or KDE products. We just hit an issue today where anaconda thinks 10G isn't enough space for a KDE live install after a grub2 update (which I think only bumped the required space veeery slightly, but enough to throw anaconda over the limit). Let's just go up to 15G for all GNOME and KDE cases where we're not at 20G. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-06-08 23:53:47 +00:00
"HDDSIZEGB": "15",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"LIVE": "1",
"PACKAGE_SET": "default",
"TEST_TARGET": "ISO"
},
"version": "*"
},
Enable aarch64 disk image testing, related fixes This sets us up to test the release-blocking aarch64 disk images (Minimal, Server and Workstation). It also allows for testing armhfp disk images on aarch64 worker hosts (though my testing of that isn't going too well so far), and fixes the initial-setup handling for a change upstream ('use password' is now the default so we don't need to choose it). We rewire disk image deployment test loading to work through the generic loader code rather than using ENTRYPOINT, as it allows us to more gracefully handle graphical (Workstation) vs. console (Server, Minimal), moving the code for handling console initial-setup to a helper function just like the code for gnome-initial-setup and having _console_ wait_login call it when appropriate. We also tweak desktop_vt a bit because now we need to switch from a console running as test to a desktop, which breaks the assumption that the highest numbered session of user test is the desktop... Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-28 21:20:16 +00:00
"fedora-Minimal-raw_xz-raw.xz-aarch64-*": {
"arch": "aarch64",
"distri": "fedora",
"flavor": "Minimal-raw_xz-raw.xz",
"settings": {
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"DEPLOY_UPLOAD_TEST": "install_arm_image_deployment_upload",
Enable aarch64 disk image testing, related fixes This sets us up to test the release-blocking aarch64 disk images (Minimal, Server and Workstation). It also allows for testing armhfp disk images on aarch64 worker hosts (though my testing of that isn't going too well so far), and fixes the initial-setup handling for a change upstream ('use password' is now the default so we don't need to choose it). We rewire disk image deployment test loading to work through the generic loader code rather than using ENTRYPOINT, as it allows us to more gracefully handle graphical (Workstation) vs. console (Server, Minimal), moving the code for handling console initial-setup to a helper function just like the code for gnome-initial-setup and having _console_ wait_login call it when appropriate. We also tweak desktop_vt a bit because now we need to switch from a console running as test to a desktop, which breaks the assumption that the highest numbered session of user test is the desktop... Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-28 21:20:16 +00:00
"TEST_TARGET": "HDD_2"
},
"version": "*"
},
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"fedora-Server-boot-iso-aarch64-*": {
"arch": "aarch64",
"distri": "fedora",
"flavor": "Server-boot-iso",
"settings": {
"TEST_TARGET": "ISO"
},
"version": "*"
},
"fedora-Server-boot-iso-ppc64le-*": {
"arch": "ppc64le",
"distri": "fedora",
"flavor": "Server-boot-iso",
"settings": {
"TEST_TARGET": "ISO"
},
"version": "*"
},
"fedora-Server-boot-iso-x86_64-*": {
"arch": "x86_64",
"distri": "fedora",
"flavor": "Server-boot-iso",
"settings": {
Try harder to apply that 3GiB RAM setting Seems it may need the magic override... Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-07-17 19:44:54 +00:00
"+QEMURAM": 3072,
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"TEST_TARGET": "ISO"
},
"version": "*"
},
"fedora-Server-dvd-iso-aarch64-*": {
"arch": "aarch64",
"distri": "fedora",
"flavor": "Server-dvd-iso",
"settings": {
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"DEPLOY_UPLOAD_TEST": "install_default_upload",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"TEST_TARGET": "ISO"
},
"version": "*"
},
"fedora-Server-dvd-iso-ppc64le-*": {
"arch": "ppc64le",
"distri": "fedora",
"flavor": "Server-dvd-iso",
"settings": {
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"DEPLOY_UPLOAD_TEST": "install_default_upload",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"TEST_TARGET": "ISO"
},
"version": "*"
},
"fedora-Server-dvd-iso-x86_64-*": {
"arch": "x86_64",
"distri": "fedora",
"flavor": "Server-dvd-iso",
"settings": {
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"DEPLOY_UPLOAD_TEST": "install_default_upload",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"TEST_TARGET": "ISO"
},
"version": "*"
},
Enable aarch64 disk image testing, related fixes This sets us up to test the release-blocking aarch64 disk images (Minimal, Server and Workstation). It also allows for testing armhfp disk images on aarch64 worker hosts (though my testing of that isn't going too well so far), and fixes the initial-setup handling for a change upstream ('use password' is now the default so we don't need to choose it). We rewire disk image deployment test loading to work through the generic loader code rather than using ENTRYPOINT, as it allows us to more gracefully handle graphical (Workstation) vs. console (Server, Minimal), moving the code for handling console initial-setup to a helper function just like the code for gnome-initial-setup and having _console_ wait_login call it when appropriate. We also tweak desktop_vt a bit because now we need to switch from a console running as test to a desktop, which breaks the assumption that the highest numbered session of user test is the desktop... Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-28 21:20:16 +00:00
"fedora-Server-raw_xz-raw.xz-aarch64-*": {
"arch": "aarch64",
"distri": "fedora",
"flavor": "Server-raw_xz-raw.xz",
"settings": {
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"DEPLOY_UPLOAD_TEST": "install_arm_image_deployment_upload",
Enable aarch64 disk image testing, related fixes This sets us up to test the release-blocking aarch64 disk images (Minimal, Server and Workstation). It also allows for testing armhfp disk images on aarch64 worker hosts (though my testing of that isn't going too well so far), and fixes the initial-setup handling for a change upstream ('use password' is now the default so we don't need to choose it). We rewire disk image deployment test loading to work through the generic loader code rather than using ENTRYPOINT, as it allows us to more gracefully handle graphical (Workstation) vs. console (Server, Minimal), moving the code for handling console initial-setup to a helper function just like the code for gnome-initial-setup and having _console_ wait_login call it when appropriate. We also tweak desktop_vt a bit because now we need to switch from a console running as test to a desktop, which breaks the assumption that the highest numbered session of user test is the desktop... Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-28 21:20:16 +00:00
"TEST_TARGET": "HDD_2"
},
"version": "*"
},
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"fedora-Silverblue-dvd_ostree-iso-ppc64le-*": {
"arch": "ppc64le",
"distri": "fedora",
"flavor": "Silverblue-dvd_ostree-iso",
"settings": {
"CANNED": "1",
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"DEPLOY_UPLOAD_TEST": "install_default_upload",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"DESKTOP": "gnome",
Make Silverblue install target disk bigger It's defaulting to 10Gi, which definitely has caused *some* issues (the flatpak test fails because there isn't enough disk space). I'm hoping this will turn out to explain why SB tests have been generally so unreliable lately. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-01-03 23:03:24 +00:00
"HDDSIZEGB": "20",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"PACKAGE_SET": "default",
"TEST_TARGET": "ISO"
},
"version": "*"
},
"fedora-Silverblue-dvd_ostree-iso-x86_64-*": {
"arch": "x86_64",
"distri": "fedora",
"flavor": "Silverblue-dvd_ostree-iso",
"settings": {
"CANNED": "1",
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"DEPLOY_UPLOAD_TEST": "install_default_upload",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"DESKTOP": "gnome",
Make Silverblue install target disk bigger It's defaulting to 10Gi, which definitely has caused *some* issues (the flatpak test fails because there isn't enough disk space). I'm hoping this will turn out to explain why SB tests have been generally so unreliable lately. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-01-03 23:03:24 +00:00
"HDDSIZEGB": "20",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"PACKAGE_SET": "default",
Bump retry count on some flaky tests The silverblue tests are flaky because of https://github.com/fedora-silverblue/issue-tracker/issues/548 . The desktop_upgrade_encrypted test is flaky on Rawhide (so, when booting from F40 initially) since we switched to UEFI, not sure if it's because of UEFI somehow or just a timing coincidence. Am going to look into it, but for now this should save lots of manual restarting. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-04-05 14:59:42 +00:00
"RETRY": "2",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"TEST_TARGET": "ISO"
},
"version": "*"
},
"fedora-Workstation-live-iso-ppc64le-*": {
"arch": "ppc64le",
"distri": "fedora",
"flavor": "Workstation-live-iso",
"settings": {
"DESKTOP": "gnome",
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"DEPLOY_UPLOAD_TEST": "install_default_upload",
Finish the post review changes.
2020-05-28 09:40:34 +00:00
"HDDSIZEGB": "20",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"LIVE": "1",
"PACKAGE_SET": "default",
"TEST_TARGET": "ISO"
},
"version": "*"
},
"fedora-Workstation-live-iso-x86_64-*": {
"arch": "x86_64",
"distri": "fedora",
"flavor": "Workstation-live-iso",
"settings": {
"DESKTOP": "gnome",
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"DEPLOY_UPLOAD_TEST": "install_default_upload",
Add to templates.
2020-05-11 13:55:16 +00:00
"HDDSIZEGB": "20",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"LIVE": "1",
"PACKAGE_SET": "default",
"TEST_TARGET": "ISO"
},
"version": "*"
},
Add tests for the Workstation live osbuild image We should test this image to make sure it works as well as the official image. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-02-21 00:06:40 +00:00
"fedora-Workstation-live_osbuild-iso-x86_64-*": {
"arch": "x86_64",
"distri": "fedora",
"flavor": "Workstation-live_osbuild-iso",
"settings": {
"DESKTOP": "gnome",
"DEPLOY_UPLOAD_TEST": "install_default_upload",
"HDDSIZEGB": "20",
"LIVE": "1",
"PACKAGE_SET": "default",
"TEST_TARGET": "ISO"
},
"version": "*"
},
Rename tests and flavours as per review.
2021-12-07 10:30:21 +00:00
"fedora-Workstation-upgrade-x86_64-*": {
Add a new flavour to test upgrade postinstall tests.
2021-11-29 08:27:58 +00:00
"arch": "x86_64",
"distri": "fedora",
Rename tests and flavours as per review.
2021-12-07 10:30:21 +00:00
"flavor": "Workstation-upgrade",
Add a new flavour to test upgrade postinstall tests.
2021-11-29 08:27:58 +00:00
"settings": {
"DESKTOP": "gnome",
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"DEPLOY_UPLOAD_TEST": "upgrade_desktop" ,
Add a new flavour to test upgrade postinstall tests.
2021-11-29 08:27:58 +00:00
"HDDSIZEGB": "20",
"PACKAGE_SET": "default",
Set TEST_TARGET to COMPOSE for upgrade flavors The ISO or HDD image won't be attached to the post-upgrade tests, and these are not tests of the image anyway, they're tests of the compose. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-06-19 18:18:44 +00:00
"TEST_TARGET": "COMPOSE"
Add a new flavour to test upgrade postinstall tests.
2021-11-29 08:27:58 +00:00
},
"version": "*"
},
Enable aarch64 disk image testing, related fixes This sets us up to test the release-blocking aarch64 disk images (Minimal, Server and Workstation). It also allows for testing armhfp disk images on aarch64 worker hosts (though my testing of that isn't going too well so far), and fixes the initial-setup handling for a change upstream ('use password' is now the default so we don't need to choose it). We rewire disk image deployment test loading to work through the generic loader code rather than using ENTRYPOINT, as it allows us to more gracefully handle graphical (Workstation) vs. console (Server, Minimal), moving the code for handling console initial-setup to a helper function just like the code for gnome-initial-setup and having _console_ wait_login call it when appropriate. We also tweak desktop_vt a bit because now we need to switch from a console running as test to a desktop, which breaks the assumption that the highest numbered session of user test is the desktop... Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-28 21:20:16 +00:00
"fedora-Workstation-raw_xz-raw.xz-aarch64-*": {
"arch": "aarch64",
"distri": "fedora",
"flavor": "Workstation-raw_xz-raw.xz",
"settings": {
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"DEPLOY_UPLOAD_TEST": "install_arm_image_deployment_upload",
Enable aarch64 disk image testing, related fixes This sets us up to test the release-blocking aarch64 disk images (Minimal, Server and Workstation). It also allows for testing armhfp disk images on aarch64 worker hosts (though my testing of that isn't going too well so far), and fixes the initial-setup handling for a change upstream ('use password' is now the default so we don't need to choose it). We rewire disk image deployment test loading to work through the generic loader code rather than using ENTRYPOINT, as it allows us to more gracefully handle graphical (Workstation) vs. console (Server, Minimal), moving the code for handling console initial-setup to a helper function just like the code for gnome-initial-setup and having _console_ wait_login call it when appropriate. We also tweak desktop_vt a bit because now we need to switch from a console running as test to a desktop, which breaks the assumption that the highest numbered session of user test is the desktop... Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-28 21:20:16 +00:00
"DESKTOP": "gnome",
"TEST_TARGET": "HDD_2"
},
"version": "*"
},
Rename tests and flavours as per review.
2021-12-07 10:30:21 +00:00
"fedora-Workstation-upgrade-aarch64-*": {
Switch on upgrades even for aarch64.
2021-12-01 11:19:13 +00:00
"arch": "aarch64",
"distri": "fedora",
Rename tests and flavours as per review.
2021-12-07 10:30:21 +00:00
"flavor": "Workstation-upgrade",
Switch on upgrades even for aarch64.
2021-12-01 11:19:13 +00:00
"settings": {
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"DEPLOY_UPLOAD_TEST": "upgrade_desktop",
Switch on upgrades even for aarch64.
2021-12-01 11:19:13 +00:00
"DESKTOP": "gnome",
Set TEST_TARGET to COMPOSE for upgrade flavors The ISO or HDD image won't be attached to the post-upgrade tests, and these are not tests of the image anyway, they're tests of the compose. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-06-19 18:18:44 +00:00
"TEST_TARGET": "COMPOSE"
Switch on upgrades even for aarch64.
2021-12-01 11:19:13 +00:00
},
"version": "*"
},
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"fedora-universal-aarch64-*": {
"arch": "aarch64",
"distri": "fedora",
"flavor": "universal",
"settings": {
Set TEST_TARGET to COMPOSE for upgrade flavors The ISO or HDD image won't be attached to the post-upgrade tests, and these are not tests of the image anyway, they're tests of the compose. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-06-19 18:18:44 +00:00
"TEST_TARGET": "COMPOSE"
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"version": "*"
},
"fedora-universal-ppc64le-*": {
"arch": "ppc64le",
"distri": "fedora",
"flavor": "universal",
"settings": {
Set TEST_TARGET to COMPOSE for upgrade flavors The ISO or HDD image won't be attached to the post-upgrade tests, and these are not tests of the image anyway, they're tests of the compose. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-06-19 18:18:44 +00:00
"TEST_TARGET": "COMPOSE"
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"version": "*"
},
"fedora-universal-x86_64-*": {
"arch": "x86_64",
"distri": "fedora",
"flavor": "universal",
"settings": {
Set TEST_TARGET to COMPOSE for upgrade flavors The ISO or HDD image won't be attached to the post-upgrade tests, and these are not tests of the image anyway, they're tests of the compose. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-06-19 18:18:44 +00:00
"TEST_TARGET": "COMPOSE"
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"version": "*"
Automate the Anaconda_Save_Traceback_to_Bugzilla_Text test case. This PR adds a new test that automates the above mentioned test case. It starts the installation in text mode using the `install_text` test case, which it interrupts using the Anaconda crash trigger. When the crash happens, it goes through the process of reporting the bug to Bugzilla, checks that Bugzilla sends a positive confirmation of the action, but also performs some REST API calls to do a proper check and then it closes the bug to clean up.
2021-04-27 11:02:53 +00:00
},
"fedora-seasonal-aarch64-*": {
"arch": "aarch64",
"distri": "fedora",
"flavor": "seasonal",
"settings": {
"TEST_TARGET": "ISO"
},
"version": "*"
},
"fedora-seasonal-ppc64le-*": {
"arch": "ppc64le",
"distri": "fedora",
"flavor": "seasonal",
"settings": {
"TEST_TARGET": "ISO"
},
"version": "*"
},
"fedora-seasonal-x86_64-*": {
"arch": "x86_64",
"distri": "fedora",
"flavor": "seasonal",
"settings": {
"TEST_TARGET": "ISO"
},
"version": "*"
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
}
},
"Profiles": {
Run ELN tests on BIOS ELN can't boot with Secure Boot enabled currently: https://github.com/fedora-eln/eln/issues/183 Until that's resolved, let's go back to testing on BIOS (this is easier than testing on non-SB UEFI for...reasons). Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-04-02 22:39:42 +00:00
"fedora-BaseOS-boot-iso-x86_64-*-bios": {
"machine": "bios",
Add initial template stuff and test tweaks for ELN testing Just a couple of flavors and tests for now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-06-19 14:01:39 +00:00
"product": "fedora-BaseOS-boot-iso-x86_64-*"
},
Run ELN tests on BIOS ELN can't boot with Secure Boot enabled currently: https://github.com/fedora-eln/eln/issues/183 Until that's resolved, let's go back to testing on BIOS (this is easier than testing on non-SB UEFI for...reasons). Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-04-02 22:39:42 +00:00
"fedora-BaseOS-dvd-iso-x86_64-*-bios": {
"machine": "bios",
Add initial template stuff and test tweaks for ELN testing Just a couple of flavors and tests for now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-06-19 14:01:39 +00:00
"product": "fedora-BaseOS-dvd-iso-x86_64-*"
},
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"fedora-Cloud_Base-qcow2-qcow2-aarch64-*-aarch64": {
"machine": "aarch64",
"product": "fedora-Cloud_Base-qcow2-qcow2-aarch64-*"
},
"fedora-Cloud_Base-qcow2-qcow2-ppc64le-*-ppc64le": {
"machine": "ppc64le",
"product": "fedora-Cloud_Base-qcow2-qcow2-ppc64le-*"
},
"fedora-Cloud_Base-qcow2-qcow2-x86_64-*-64bit": {
"machine": "64bit",
"product": "fedora-Cloud_Base-qcow2-qcow2-x86_64-*"
},
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Cloud_Base-qcow2-qcow2-x86_64-*-bios": {
"machine": "bios",
Add missing profile from previous commit Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-11-03 17:04:11 +00:00
"product": "fedora-Cloud_Base-qcow2-qcow2-x86_64-*"
},
Add initial CoreOS product and test templates Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-08-19 21:58:02 +00:00
"fedora-CoreOS-colive-iso-x86_64-*-64bit": {
"machine": "64bit",
"product": "fedora-CoreOS-colive-iso-x86_64-*"
},
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-CoreOS-colive-iso-x86_64-*-bios": {
"machine": "bios",
"product": "fedora-CoreOS-colive-iso-x86_64-*"
},
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"fedora-Everything-boot-iso-ppc64le-*-ppc64le": {
"machine": "ppc64le",
"product": "fedora-Everything-boot-iso-ppc64le-*"
},
"fedora-Everything-boot-iso-x86_64-*-64bit": {
"machine": "64bit",
"product": "fedora-Everything-boot-iso-x86_64-*"
},
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Everything-boot-iso-x86_64-*-bios": {
"machine": "bios",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"product": "fedora-Everything-boot-iso-x86_64-*"
},
Enable IoT testing with install and base tests IoT is becoming a release-blocking edition for F32, so we should be testing it for sure. We may add specific tests, but for now let's run the install and base tests on it. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-02-13 19:50:32 +00:00
"fedora-IoT-dvd_ostree-iso-aarch64-*-aarch64": {
"machine": "aarch64",
"product": "fedora-IoT-dvd_ostree-iso-aarch64-*"
},
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-IoT-dvd_ostree-iso-x86_64-*-64bit": {
"machine": "64bit",
Enable IoT testing with install and base tests IoT is becoming a release-blocking edition for F32, so we should be testing it for sure. We may add specific tests, but for now let's run the install and base tests on it. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-02-13 19:50:32 +00:00
"product": "fedora-IoT-dvd_ostree-iso-x86_64-*"
},
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"fedora-KDE-live-iso-x86_64-*-64bit": {
"machine": "64bit",
"product": "fedora-KDE-live-iso-x86_64-*"
},
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-KDE-live-iso-x86_64-*-bios": {
"machine": "bios",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"product": "fedora-KDE-live-iso-x86_64-*"
},
Enable aarch64 disk image testing, related fixes This sets us up to test the release-blocking aarch64 disk images (Minimal, Server and Workstation). It also allows for testing armhfp disk images on aarch64 worker hosts (though my testing of that isn't going too well so far), and fixes the initial-setup handling for a change upstream ('use password' is now the default so we don't need to choose it). We rewire disk image deployment test loading to work through the generic loader code rather than using ENTRYPOINT, as it allows us to more gracefully handle graphical (Workstation) vs. console (Server, Minimal), moving the code for handling console initial-setup to a helper function just like the code for gnome-initial-setup and having _console_ wait_login call it when appropriate. We also tweak desktop_vt a bit because now we need to switch from a console running as test to a desktop, which breaks the assumption that the highest numbered session of user test is the desktop... Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-28 21:20:16 +00:00
"fedora-Minimal-raw_xz-raw.xz-aarch64-*-aarch64": {
"machine": "aarch64",
"product": "fedora-Minimal-raw_xz-raw.xz-aarch64-*"
},
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"fedora-Server-boot-iso-aarch64-*-aarch64": {
"machine": "aarch64",
"product": "fedora-Server-boot-iso-aarch64-*"
},
"fedora-Server-boot-iso-ppc64le-*-ppc64le": {
"machine": "ppc64le",
"product": "fedora-Server-boot-iso-ppc64le-*"
},
"fedora-Server-boot-iso-x86_64-*-64bit": {
"machine": "64bit",
"product": "fedora-Server-boot-iso-x86_64-*"
},
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Server-boot-iso-x86_64-*-bios": {
"machine": "bios",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"product": "fedora-Server-boot-iso-x86_64-*"
},
"fedora-Server-dvd-iso-aarch64-*-aarch64": {
"machine": "aarch64",
"product": "fedora-Server-dvd-iso-aarch64-*"
},
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": {
"machine": "ppc64le",
"product": "fedora-Server-dvd-iso-ppc64le-*"
},
"fedora-Server-dvd-iso-x86_64-*-64bit": {
"machine": "64bit",
"product": "fedora-Server-dvd-iso-x86_64-*"
},
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Server-dvd-iso-x86_64-*-bios": {
"machine": "bios",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"product": "fedora-Server-dvd-iso-x86_64-*"
},
Enable aarch64 disk image testing, related fixes This sets us up to test the release-blocking aarch64 disk images (Minimal, Server and Workstation). It also allows for testing armhfp disk images on aarch64 worker hosts (though my testing of that isn't going too well so far), and fixes the initial-setup handling for a change upstream ('use password' is now the default so we don't need to choose it). We rewire disk image deployment test loading to work through the generic loader code rather than using ENTRYPOINT, as it allows us to more gracefully handle graphical (Workstation) vs. console (Server, Minimal), moving the code for handling console initial-setup to a helper function just like the code for gnome-initial-setup and having _console_ wait_login call it when appropriate. We also tweak desktop_vt a bit because now we need to switch from a console running as test to a desktop, which breaks the assumption that the highest numbered session of user test is the desktop... Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-28 21:20:16 +00:00
"fedora-Server-raw_xz-raw.xz-aarch64-*-aarch64": {
"machine": "aarch64",
"product": "fedora-Server-raw_xz-raw.xz-aarch64-*"
},
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"fedora-Silverblue-dvd_ostree-iso-ppc64le-*-ppc64le": {
"machine": "ppc64le",
"product": "fedora-Silverblue-dvd_ostree-iso-ppc64le-*"
},
"fedora-Silverblue-dvd_ostree-iso-x86_64-*-64bit": {
"machine": "64bit",
"product": "fedora-Silverblue-dvd_ostree-iso-x86_64-*"
},
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Silverblue-dvd_ostree-iso-x86_64-*-bios": {
"machine": "bios",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"product": "fedora-Silverblue-dvd_ostree-iso-x86_64-*"
},
"fedora-Workstation-live-iso-ppc64le-*-ppc64le": {
"machine": "ppc64le",
"product": "fedora-Workstation-live-iso-ppc64le-*"
},
"fedora-Workstation-live-iso-x86_64-*-64bit": {
"machine": "64bit",
"product": "fedora-Workstation-live-iso-x86_64-*"
},
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Workstation-live-iso-x86_64-*-bios": {
"machine": "bios",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"product": "fedora-Workstation-live-iso-x86_64-*"
},
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Workstation-live_osbuild-iso-x86_64-*-64bit": {
"machine": "64bit",
Add tests for the Workstation live osbuild image We should test this image to make sure it works as well as the official image. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-02-21 00:06:40 +00:00
"product": "fedora-Workstation-live_osbuild-iso-x86_64-*"
},
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Workstation-upgrade-x86_64-*-64bit": {
"machine": "64bit",
"product": "fedora-Workstation-upgrade-x86_64-*"
},
Enable aarch64 disk image testing, related fixes This sets us up to test the release-blocking aarch64 disk images (Minimal, Server and Workstation). It also allows for testing armhfp disk images on aarch64 worker hosts (though my testing of that isn't going too well so far), and fixes the initial-setup handling for a change upstream ('use password' is now the default so we don't need to choose it). We rewire disk image deployment test loading to work through the generic loader code rather than using ENTRYPOINT, as it allows us to more gracefully handle graphical (Workstation) vs. console (Server, Minimal), moving the code for handling console initial-setup to a helper function just like the code for gnome-initial-setup and having _console_ wait_login call it when appropriate. We also tweak desktop_vt a bit because now we need to switch from a console running as test to a desktop, which breaks the assumption that the highest numbered session of user test is the desktop... Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-28 21:20:16 +00:00
"fedora-Workstation-raw_xz-raw.xz-aarch64-*-aarch64": {
"machine": "aarch64",
"product": "fedora-Workstation-raw_xz-raw.xz-aarch64-*"
},
Rename tests and flavours as per review.
2021-12-07 10:30:21 +00:00
"fedora-Workstation-upgrade-aarch64-*-aarch64": {
Switch on upgrades even for aarch64.
2021-12-01 11:19:13 +00:00
"machine": "aarch64",
Rename tests and flavours as per review.
2021-12-07 10:30:21 +00:00
"product": "fedora-Workstation-upgrade-aarch64-*"
Switch on upgrades even for aarch64.
2021-12-01 11:19:13 +00:00
},
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"fedora-universal-aarch64-*-aarch64": {
"machine": "aarch64",
"product": "fedora-universal-aarch64-*"
},
"fedora-universal-ppc64le-*-ppc64le": {
"machine": "ppc64le",
"product": "fedora-universal-ppc64le-*"
},
"fedora-universal-x86_64-*-64bit": {
"machine": "64bit",
"product": "fedora-universal-x86_64-*"
},
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-universal-x86_64-*-bios": {
"machine": "bios",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"product": "fedora-universal-x86_64-*"
Automate the Anaconda_Save_Traceback_to_Bugzilla_Text test case. This PR adds a new test that automates the above mentioned test case. It starts the installation in text mode using the `install_text` test case, which it interrupts using the Anaconda crash trigger. When the crash happens, it goes through the process of reporting the bug to Bugzilla, checks that Bugzilla sends a positive confirmation of the action, but also performs some REST API calls to do a proper check and then it closes the bug to clean up.
2021-04-27 11:02:53 +00:00
},
"fedora-seasonal-aarch64-*-aarch64": {
"machine": "aarch64",
"product": "fedora-seasonal-aarch64-*"
},
"fedora-seasonal-ppc64le-*-ppc64le": {
"machine": "ppc64le",
"product": "fedora-seasonal-ppc64le-*"
},
"fedora-seasonal-x86_64-*-64bit": {
"machine": "64bit",
"product": "fedora-seasonal-x86_64-*"
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
}
},
"TestSuites": {
"apps_startstop": {
"profiles": {
"fedora-KDE-live-iso-x86_64-*-64bit": 40,
"fedora-Workstation-live-iso-ppc64le-*-ppc64le": 40,
Rename tests and flavours as per review.
2021-12-07 10:30:21 +00:00
"fedora-Workstation-upgrade-x86_64-*-64bit": 40,
Add tests for the Workstation live osbuild image We should test this image to make sure it works as well as the official image. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-02-21 00:06:40 +00:00
"fedora-Workstation-live-iso-x86_64-*-64bit": 40,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Workstation-live_osbuild-iso-x86_64-*-64bit": 70
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"STARTSTOP": "true",
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%"
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
}
},
"base_reboot_unmount": {
"profiles": {
Run ELN tests on BIOS ELN can't boot with Secure Boot enabled currently: https://github.com/fedora-eln/eln/issues/183 Until that's resolved, let's go back to testing on BIOS (this is easier than testing on non-SB UEFI for...reasons). Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-04-02 22:39:42 +00:00
"fedora-BaseOS-dvd-iso-x86_64-*-bios": 50,
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"fedora-Cloud_Base-qcow2-qcow2-aarch64-*-aarch64": 20,
"fedora-Cloud_Base-qcow2-qcow2-ppc64le-*-ppc64le": 20,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Cloud_Base-qcow2-qcow2-x86_64-*-bios": 20,
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"fedora-Cloud_Base-qcow2-qcow2-x86_64-*-64bit": 20,
Enable more base tests on aarch64 images, fix up priorities a bit Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:57:24 +00:00
"fedora-CoreOS-colive-iso-x86_64-*-64bit": 50,
Enable IoT testing with install and base tests IoT is becoming a release-blocking edition for F32, so we should be testing it for sure. We may add specific tests, but for now let's run the install and base tests on it. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-02-13 19:50:32 +00:00
"fedora-IoT-dvd_ostree-iso-aarch64-*-aarch64": 20,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-IoT-dvd_ostree-iso-x86_64-*-64bit": 20,
base tests: run on Cloud, add one on aarch64, clean up priorities This adds new variant test suites for several of the base tests to run them on Cloud disk images. We can't re-use the existing test suites because they have `START_AFTER_TEST` defined and there's no viable way to undefine it (there are things you can do to override the value, but you can't just unset it). Also add a stray test we weren't running on aarch64, and correct some priorities. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-06-17 22:18:21 +00:00
"fedora-KDE-live-iso-x86_64-*-64bit": 22,
Enable more base tests on aarch64 images, fix up priorities a bit Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:57:24 +00:00
"fedora-Minimal-raw_xz-raw.xz-aarch64-*-aarch64": 22,
base tests: run on Cloud, add one on aarch64, clean up priorities This adds new variant test suites for several of the base tests to run them on Cloud disk images. We can't re-use the existing test suites because they have `START_AFTER_TEST` defined and there's no viable way to undefine it (there are things you can do to override the value, but you can't just unset it). Also add a stray test we weren't running on aarch64, and correct some priorities. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-06-17 22:18:21 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 20,
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 20,
base tests: run on Cloud, add one on aarch64, clean up priorities This adds new variant test suites for several of the base tests to run them on Cloud disk images. We can't re-use the existing test suites because they have `START_AFTER_TEST` defined and there's no viable way to undefine it (there are things you can do to override the value, but you can't just unset it). Also add a stray test we weren't running on aarch64, and correct some priorities. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-06-17 22:18:21 +00:00
"fedora-Server-dvd-iso-x86_64-*-64bit": 20,
Enable more base tests on aarch64 images, fix up priorities a bit Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:57:24 +00:00
"fedora-Server-raw_xz-raw.xz-aarch64-*-aarch64": 22,
base tests: run on Cloud, add one on aarch64, clean up priorities This adds new variant test suites for several of the base tests to run them on Cloud disk images. We can't re-use the existing test suites because they have `START_AFTER_TEST` defined and there's no viable way to undefine it (there are things you can do to override the value, but you can't just unset it). Also add a stray test we weren't running on aarch64, and correct some priorities. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-06-17 22:18:21 +00:00
"fedora-Silverblue-dvd_ostree-iso-ppc64le-*-ppc64le": 50,
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"fedora-Silverblue-dvd_ostree-iso-x86_64-*-64bit": 50,
"fedora-Workstation-live-iso-ppc64le-*-ppc64le": 20,
Enable more base tests on aarch64 images, fix up priorities a bit Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:57:24 +00:00
"fedora-Workstation-live-iso-x86_64-*-64bit": 20,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Workstation-live_osbuild-iso-x86_64-*-64bit": 70,
Rename tests and flavours as per review.
2021-12-07 10:30:21 +00:00
"fedora-Workstation-upgrade-x86_64-*-64bit": 40,
Switch on upgrades even for aarch64.
2021-12-01 11:19:13 +00:00
"fedora-Workstation-raw_xz-raw.xz-aarch64-*-aarch64": 22,
Rename tests and flavours as per review.
2021-12-07 10:30:21 +00:00
"fedora-Workstation-upgrade-aarch64-*-aarch64": 40
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"POSTINSTALL": "base_reboot_unmount",
"ROOT_PASSWORD": "weakpassword",
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"USER_LOGIN": "false"
}
},
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"base_system_logging": {
base tests: run on Cloud, add one on aarch64, clean up priorities This adds new variant test suites for several of the base tests to run them on Cloud disk images. We can't re-use the existing test suites because they have `START_AFTER_TEST` defined and there's no viable way to undefine it (there are things you can do to override the value, but you can't just unset it). Also add a stray test we weren't running on aarch64, and correct some priorities. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-06-17 22:18:21 +00:00
"profiles": {
Run ELN tests on BIOS ELN can't boot with Secure Boot enabled currently: https://github.com/fedora-eln/eln/issues/183 Until that's resolved, let's go back to testing on BIOS (this is easier than testing on non-SB UEFI for...reasons). Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-04-02 22:39:42 +00:00
"fedora-BaseOS-dvd-iso-x86_64-*-bios": 50,
base tests: run on Cloud, add one on aarch64, clean up priorities This adds new variant test suites for several of the base tests to run them on Cloud disk images. We can't re-use the existing test suites because they have `START_AFTER_TEST` defined and there's no viable way to undefine it (there are things you can do to override the value, but you can't just unset it). Also add a stray test we weren't running on aarch64, and correct some priorities. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-06-17 22:18:21 +00:00
"fedora-Cloud_Base-qcow2-qcow2-aarch64-*-aarch64": 20,
"fedora-Cloud_Base-qcow2-qcow2-ppc64le-*-ppc64le": 20,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Cloud_Base-qcow2-qcow2-x86_64-*-64bit": 20,
Enable more base tests on aarch64 images, fix up priorities a bit Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:57:24 +00:00
"fedora-CoreOS-colive-iso-x86_64-*-64bit": 50,
Enable IoT testing with install and base tests IoT is becoming a release-blocking edition for F32, so we should be testing it for sure. We may add specific tests, but for now let's run the install and base tests on it. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-02-13 19:50:32 +00:00
"fedora-IoT-dvd_ostree-iso-aarch64-*-aarch64": 20,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-IoT-dvd_ostree-iso-x86_64-*-64bit": 20,
base tests: run on Cloud, add one on aarch64, clean up priorities This adds new variant test suites for several of the base tests to run them on Cloud disk images. We can't re-use the existing test suites because they have `START_AFTER_TEST` defined and there's no viable way to undefine it (there are things you can do to override the value, but you can't just unset it). Also add a stray test we weren't running on aarch64, and correct some priorities. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-06-17 22:18:21 +00:00
"fedora-KDE-live-iso-x86_64-*-64bit": 22,
Enable more base tests on aarch64 images, fix up priorities a bit Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:57:24 +00:00
"fedora-Minimal-raw_xz-raw.xz-aarch64-*-aarch64": 22,
base tests: run on Cloud, add one on aarch64, clean up priorities This adds new variant test suites for several of the base tests to run them on Cloud disk images. We can't re-use the existing test suites because they have `START_AFTER_TEST` defined and there's no viable way to undefine it (there are things you can do to override the value, but you can't just unset it). Also add a stray test we weren't running on aarch64, and correct some priorities. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-06-17 22:18:21 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 20,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 20,
"fedora-Server-dvd-iso-x86_64-*-64bit": 20,
Enable more base tests on aarch64 images, fix up priorities a bit Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:57:24 +00:00
"fedora-Server-raw_xz-raw.xz-aarch64-*-aarch64": 22,
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"fedora-Silverblue-dvd_ostree-iso-ppc64le-*-ppc64le": 50,
"fedora-Silverblue-dvd_ostree-iso-x86_64-*-64bit": 50,
base tests: run on Cloud, add one on aarch64, clean up priorities This adds new variant test suites for several of the base tests to run them on Cloud disk images. We can't re-use the existing test suites because they have `START_AFTER_TEST` defined and there's no viable way to undefine it (there are things you can do to override the value, but you can't just unset it). Also add a stray test we weren't running on aarch64, and correct some priorities. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-06-17 22:18:21 +00:00
"fedora-Workstation-live-iso-ppc64le-*-ppc64le": 20,
Enable more base tests on aarch64 images, fix up priorities a bit Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:57:24 +00:00
"fedora-Workstation-live-iso-x86_64-*-64bit": 20,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Workstation-live_osbuild-iso-x86_64-*-64bit": 70,
Rename tests and flavours as per review.
2021-12-07 10:30:21 +00:00
"fedora-Workstation-upgrade-x86_64-*-64bit": 40,
"fedora-Workstation-upgrade-aarch64-*-aarch64": 40,
Enable more base tests on aarch64 images, fix up priorities a bit Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:57:24 +00:00
"fedora-Workstation-raw_xz-raw.xz-aarch64-*-aarch64": 22
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
base tests: run on Cloud, add one on aarch64, clean up priorities This adds new variant test suites for several of the base tests to run them on Cloud disk images. We can't re-use the existing test suites because they have `START_AFTER_TEST` defined and there's no viable way to undefine it (there are things you can do to override the value, but you can't just unset it). Also add a stray test we weren't running on aarch64, and correct some priorities. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-06-17 22:18:21 +00:00
"POSTINSTALL": "base_system_logging",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"ROOT_PASSWORD": "weakpassword",
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"USER_LOGIN": "false"
}
},
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"base_update_cli": {
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"profiles": {
Run ELN tests on BIOS ELN can't boot with Secure Boot enabled currently: https://github.com/fedora-eln/eln/issues/183 Until that's resolved, let's go back to testing on BIOS (this is easier than testing on non-SB UEFI for...reasons). Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-04-02 22:39:42 +00:00
"fedora-BaseOS-dvd-iso-x86_64-*-bios": 50,
base tests: run on Cloud, add one on aarch64, clean up priorities This adds new variant test suites for several of the base tests to run them on Cloud disk images. We can't re-use the existing test suites because they have `START_AFTER_TEST` defined and there's no viable way to undefine it (there are things you can do to override the value, but you can't just unset it). Also add a stray test we weren't running on aarch64, and correct some priorities. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-06-17 22:18:21 +00:00
"fedora-Cloud_Base-qcow2-qcow2-aarch64-*-aarch64": 20,
"fedora-Cloud_Base-qcow2-qcow2-ppc64le-*-ppc64le": 20,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Cloud_Base-qcow2-qcow2-x86_64-*-64bit": 20,
base tests: run on Cloud, add one on aarch64, clean up priorities This adds new variant test suites for several of the base tests to run them on Cloud disk images. We can't re-use the existing test suites because they have `START_AFTER_TEST` defined and there's no viable way to undefine it (there are things you can do to override the value, but you can't just unset it). Also add a stray test we weren't running on aarch64, and correct some priorities. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-06-17 22:18:21 +00:00
"fedora-KDE-live-iso-x86_64-*-64bit": 22,
Enable more base tests on aarch64 images, fix up priorities a bit Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:57:24 +00:00
"fedora-Minimal-raw_xz-raw.xz-aarch64-*-aarch64": 22,
base tests: run on Cloud, add one on aarch64, clean up priorities This adds new variant test suites for several of the base tests to run them on Cloud disk images. We can't re-use the existing test suites because they have `START_AFTER_TEST` defined and there's no viable way to undefine it (there are things you can do to override the value, but you can't just unset it). Also add a stray test we weren't running on aarch64, and correct some priorities. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-06-17 22:18:21 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 20,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 20,
"fedora-Server-dvd-iso-x86_64-*-64bit": 20,
Enable more base tests on aarch64 images, fix up priorities a bit Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:57:24 +00:00
"fedora-Server-raw_xz-raw.xz-aarch64-*-aarch64": 22,
base tests: run on Cloud, add one on aarch64, clean up priorities This adds new variant test suites for several of the base tests to run them on Cloud disk images. We can't re-use the existing test suites because they have `START_AFTER_TEST` defined and there's no viable way to undefine it (there are things you can do to override the value, but you can't just unset it). Also add a stray test we weren't running on aarch64, and correct some priorities. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-06-17 22:18:21 +00:00
"fedora-Workstation-live-iso-ppc64le-*-ppc64le": 20,
Enable more base tests on aarch64 images, fix up priorities a bit Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:57:24 +00:00
"fedora-Workstation-live-iso-x86_64-*-64bit": 20,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Workstation-live_osbuild-iso-x86_64-*-64bit": 70,
Rename tests and flavours as per review.
2021-12-07 10:30:21 +00:00
"fedora-Workstation-upgrade-x86_64-*-64bit": 40,
"fedora-Workstation-upgrade-aarch64-*-aarch64": 40,
Enable more base tests on aarch64 images, fix up priorities a bit Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:57:24 +00:00
"fedora-Workstation-raw_xz-raw.xz-aarch64-*-aarch64": 22
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
base tests: run on Cloud, add one on aarch64, clean up priorities This adds new variant test suites for several of the base tests to run them on Cloud disk images. We can't re-use the existing test suites because they have `START_AFTER_TEST` defined and there's no viable way to undefine it (there are things you can do to override the value, but you can't just unset it). Also add a stray test we weren't running on aarch64, and correct some priorities. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-06-17 22:18:21 +00:00
"POSTINSTALL": "base_update_cli",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"ROOT_PASSWORD": "weakpassword",
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"USER_LOGIN": "false"
}
},
Add testcase to test the Package_install_remove testcase.
2021-03-15 17:40:42 +00:00
"base_package_install_remove": {
"profiles": {
Run ELN tests on BIOS ELN can't boot with Secure Boot enabled currently: https://github.com/fedora-eln/eln/issues/183 Until that's resolved, let's go back to testing on BIOS (this is easier than testing on non-SB UEFI for...reasons). Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-04-02 22:39:42 +00:00
"fedora-BaseOS-dvd-iso-x86_64-*-bios": 50,
Add testcase to test the Package_install_remove testcase.
2021-03-15 17:40:42 +00:00
"fedora-Cloud_Base-qcow2-qcow2-aarch64-*-aarch64": 40,
"fedora-Cloud_Base-qcow2-qcow2-ppc64le-*-ppc64le": 40,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Cloud_Base-qcow2-qcow2-x86_64-*-64bit": 40,
Add testcase to test the Package_install_remove testcase.
2021-03-15 17:40:42 +00:00
"fedora-KDE-live-iso-x86_64-*-64bit": 42,
"fedora-Minimal-raw_xz-raw.xz-aarch64-*-aarch64": 42,
"fedora-Server-dvd-iso-aarch64-*-aarch64": 40,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 40,
"fedora-Server-dvd-iso-x86_64-*-64bit": 40,
"fedora-Server-raw_xz-raw.xz-aarch64-*-aarch64": 42,
"fedora-Workstation-live-iso-ppc64le-*-ppc64le": 40,
"fedora-Workstation-live-iso-x86_64-*-64bit": 40,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Workstation-live_osbuild-iso-x86_64-*-64bit": 70,
Rename tests and flavours as per review.
2021-12-07 10:30:21 +00:00
"fedora-Workstation-upgrade-x86_64-*-64bit": 40,
"fedora-Workstation-upgrade-aarch64-*-aarch64": 40,
Add testcase to test the Package_install_remove testcase.
2021-03-15 17:40:42 +00:00
"fedora-Workstation-raw_xz-raw.xz-aarch64-*-aarch64": 42
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"POSTINSTALL": "base_package_install_remove",
"ROOT_PASSWORD": "weakpassword",
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%",
"USER_LOGIN": "false"
}
},
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"base_services_start": {
"profiles": {
Run ELN tests on BIOS ELN can't boot with Secure Boot enabled currently: https://github.com/fedora-eln/eln/issues/183 Until that's resolved, let's go back to testing on BIOS (this is easier than testing on non-SB UEFI for...reasons). Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-04-02 22:39:42 +00:00
"fedora-BaseOS-dvd-iso-x86_64-*-bios": 50,
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"fedora-Cloud_Base-qcow2-qcow2-aarch64-*-aarch64": 40,
"fedora-Cloud_Base-qcow2-qcow2-ppc64le-*-ppc64le": 40,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Cloud_Base-qcow2-qcow2-x86_64-*-bios": 40,
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"fedora-Cloud_Base-qcow2-qcow2-x86_64-*-64bit": 40,
Enable more base tests on aarch64 images, fix up priorities a bit Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:57:24 +00:00
"fedora-CoreOS-colive-iso-x86_64-*-64bit": 50,
Enable IoT testing with install and base tests IoT is becoming a release-blocking edition for F32, so we should be testing it for sure. We may add specific tests, but for now let's run the install and base tests on it. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-02-13 19:50:32 +00:00
"fedora-IoT-dvd_ostree-iso-aarch64-*-aarch64": 40,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-IoT-dvd_ostree-iso-x86_64-*-64bit": 40,
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"fedora-KDE-live-iso-x86_64-*-64bit": 42,
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"fedora-Minimal-raw_xz-raw.xz-aarch64-*-aarch64": 42,
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 40,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 40,
"fedora-Server-dvd-iso-x86_64-*-64bit": 40,
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"fedora-Server-raw_xz-raw.xz-aarch64-*-aarch64": 42,
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"fedora-Silverblue-dvd_ostree-iso-ppc64le-*-ppc64le": 50,
"fedora-Silverblue-dvd_ostree-iso-x86_64-*-64bit": 50,
"fedora-Workstation-live-iso-ppc64le-*-ppc64le": 40,
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"fedora-Workstation-live-iso-x86_64-*-64bit": 40,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Workstation-live_osbuild-iso-x86_64-*-64bit": 70,
Rename tests and flavours as per review.
2021-12-07 10:30:21 +00:00
"fedora-Workstation-upgrade-x86_64-*-64bit": 40,
"fedora-Workstation-upgrade-aarch64-*-aarch64": 40,
Enable aarch64 disk image testing, related fixes This sets us up to test the release-blocking aarch64 disk images (Minimal, Server and Workstation). It also allows for testing armhfp disk images on aarch64 worker hosts (though my testing of that isn't going too well so far), and fixes the initial-setup handling for a change upstream ('use password' is now the default so we don't need to choose it). We rewire disk image deployment test loading to work through the generic loader code rather than using ENTRYPOINT, as it allows us to more gracefully handle graphical (Workstation) vs. console (Server, Minimal), moving the code for handling console initial-setup to a helper function just like the code for gnome-initial-setup and having _console_ wait_login call it when appropriate. We also tweak desktop_vt a bit because now we need to switch from a console running as test to a desktop, which breaks the assumption that the highest numbered session of user test is the desktop... Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-28 21:20:16 +00:00
"fedora-Workstation-raw_xz-raw.xz-aarch64-*-aarch64": 42
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"BOOTFROM": "c",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"POSTINSTALL": "base_services_start",
"ROOT_PASSWORD": "weakpassword",
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"USER_LOGIN": "false"
}
},
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"base_selinux": {
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"profiles": {
Run ELN tests on BIOS ELN can't boot with Secure Boot enabled currently: https://github.com/fedora-eln/eln/issues/183 Until that's resolved, let's go back to testing on BIOS (this is easier than testing on non-SB UEFI for...reasons). Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-04-02 22:39:42 +00:00
"fedora-BaseOS-dvd-iso-x86_64-*-bios": 50,
base tests: run on Cloud, add one on aarch64, clean up priorities This adds new variant test suites for several of the base tests to run them on Cloud disk images. We can't re-use the existing test suites because they have `START_AFTER_TEST` defined and there's no viable way to undefine it (there are things you can do to override the value, but you can't just unset it). Also add a stray test we weren't running on aarch64, and correct some priorities. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-06-17 22:18:21 +00:00
"fedora-Cloud_Base-qcow2-qcow2-aarch64-*-aarch64": 40,
"fedora-Cloud_Base-qcow2-qcow2-ppc64le-*-ppc64le": 40,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Cloud_Base-qcow2-qcow2-x86_64-*-64bit": 40,
Enable more base tests on aarch64 images, fix up priorities a bit Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:57:24 +00:00
"fedora-CoreOS-colive-iso-x86_64-*-64bit": 50,
base tests: run on Cloud, add one on aarch64, clean up priorities This adds new variant test suites for several of the base tests to run them on Cloud disk images. We can't re-use the existing test suites because they have `START_AFTER_TEST` defined and there's no viable way to undefine it (there are things you can do to override the value, but you can't just unset it). Also add a stray test we weren't running on aarch64, and correct some priorities. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-06-17 22:18:21 +00:00
"fedora-IoT-dvd_ostree-iso-aarch64-*-aarch64": 40,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-IoT-dvd_ostree-iso-x86_64-*-64bit": 40,
base tests: run on Cloud, add one on aarch64, clean up priorities This adds new variant test suites for several of the base tests to run them on Cloud disk images. We can't re-use the existing test suites because they have `START_AFTER_TEST` defined and there's no viable way to undefine it (there are things you can do to override the value, but you can't just unset it). Also add a stray test we weren't running on aarch64, and correct some priorities. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-06-17 22:18:21 +00:00
"fedora-KDE-live-iso-x86_64-*-64bit": 42,
Enable more base tests on aarch64 images, fix up priorities a bit Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:57:24 +00:00
"fedora-Minimal-raw_xz-raw.xz-aarch64-*-aarch64": 42,
base tests: run on Cloud, add one on aarch64, clean up priorities This adds new variant test suites for several of the base tests to run them on Cloud disk images. We can't re-use the existing test suites because they have `START_AFTER_TEST` defined and there's no viable way to undefine it (there are things you can do to override the value, but you can't just unset it). Also add a stray test we weren't running on aarch64, and correct some priorities. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-06-17 22:18:21 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 40,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 40,
"fedora-Server-dvd-iso-x86_64-*-64bit": 40,
Enable more base tests on aarch64 images, fix up priorities a bit Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:57:24 +00:00
"fedora-Server-raw_xz-raw.xz-aarch64-*-aarch64": 42,
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"fedora-Silverblue-dvd_ostree-iso-ppc64le-*-ppc64le": 50,
"fedora-Silverblue-dvd_ostree-iso-x86_64-*-64bit": 50,
base tests: run on Cloud, add one on aarch64, clean up priorities This adds new variant test suites for several of the base tests to run them on Cloud disk images. We can't re-use the existing test suites because they have `START_AFTER_TEST` defined and there's no viable way to undefine it (there are things you can do to override the value, but you can't just unset it). Also add a stray test we weren't running on aarch64, and correct some priorities. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-06-17 22:18:21 +00:00
"fedora-Workstation-live-iso-ppc64le-*-ppc64le": 40,
Enable more base tests on aarch64 images, fix up priorities a bit Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:57:24 +00:00
"fedora-Workstation-live-iso-x86_64-*-64bit": 40,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Workstation-live_osbuild-iso-x86_64-*-64bit": 70,
Rename tests and flavours as per review.
2021-12-07 10:30:21 +00:00
"fedora-Workstation-upgrade-x86_64-*-64bit": 40,
"fedora-Workstation-upgrade-aarch64-*-aarch64": 40,
Enable more base tests on aarch64 images, fix up priorities a bit Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:57:24 +00:00
"fedora-Workstation-raw_xz-raw.xz-aarch64-*-aarch64": 42
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
base tests: run on Cloud, add one on aarch64, clean up priorities This adds new variant test suites for several of the base tests to run them on Cloud disk images. We can't re-use the existing test suites because they have `START_AFTER_TEST` defined and there's no viable way to undefine it (there are things you can do to override the value, but you can't just unset it). Also add a stray test we weren't running on aarch64, and correct some priorities. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-06-17 22:18:21 +00:00
"POSTINSTALL": "base_selinux",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"ROOT_PASSWORD": "weakpassword",
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"USER_LOGIN": "false"
}
},
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"base_service_manipulation": {
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"profiles": {
Run ELN tests on BIOS ELN can't boot with Secure Boot enabled currently: https://github.com/fedora-eln/eln/issues/183 Until that's resolved, let's go back to testing on BIOS (this is easier than testing on non-SB UEFI for...reasons). Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-04-02 22:39:42 +00:00
"fedora-BaseOS-dvd-iso-x86_64-*-bios": 50,
base tests: run on Cloud, add one on aarch64, clean up priorities This adds new variant test suites for several of the base tests to run them on Cloud disk images. We can't re-use the existing test suites because they have `START_AFTER_TEST` defined and there's no viable way to undefine it (there are things you can do to override the value, but you can't just unset it). Also add a stray test we weren't running on aarch64, and correct some priorities. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-06-17 22:18:21 +00:00
"fedora-Cloud_Base-qcow2-qcow2-aarch64-*-aarch64": 40,
"fedora-Cloud_Base-qcow2-qcow2-ppc64le-*-ppc64le": 40,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Cloud_Base-qcow2-qcow2-x86_64-*-64bit": 40,
Enable more base tests on aarch64 images, fix up priorities a bit Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:57:24 +00:00
"fedora-CoreOS-colive-iso-x86_64-*-64bit": 50,
base tests: run on Cloud, add one on aarch64, clean up priorities This adds new variant test suites for several of the base tests to run them on Cloud disk images. We can't re-use the existing test suites because they have `START_AFTER_TEST` defined and there's no viable way to undefine it (there are things you can do to override the value, but you can't just unset it). Also add a stray test we weren't running on aarch64, and correct some priorities. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-06-17 22:18:21 +00:00
"fedora-IoT-dvd_ostree-iso-aarch64-*-aarch64": 40,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-IoT-dvd_ostree-iso-x86_64-*-64bit": 40,
base tests: run on Cloud, add one on aarch64, clean up priorities This adds new variant test suites for several of the base tests to run them on Cloud disk images. We can't re-use the existing test suites because they have `START_AFTER_TEST` defined and there's no viable way to undefine it (there are things you can do to override the value, but you can't just unset it). Also add a stray test we weren't running on aarch64, and correct some priorities. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-06-17 22:18:21 +00:00
"fedora-KDE-live-iso-x86_64-*-64bit": 42,
Enable more base tests on aarch64 images, fix up priorities a bit Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:57:24 +00:00
"fedora-Minimal-raw_xz-raw.xz-aarch64-*-aarch64": 42,
base tests: run on Cloud, add one on aarch64, clean up priorities This adds new variant test suites for several of the base tests to run them on Cloud disk images. We can't re-use the existing test suites because they have `START_AFTER_TEST` defined and there's no viable way to undefine it (there are things you can do to override the value, but you can't just unset it). Also add a stray test we weren't running on aarch64, and correct some priorities. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-06-17 22:18:21 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 40,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 40,
"fedora-Server-dvd-iso-x86_64-*-64bit": 40,
Enable more base tests on aarch64 images, fix up priorities a bit Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:57:24 +00:00
"fedora-Server-raw_xz-raw.xz-aarch64-*-aarch64": 42,
base tests: run on Cloud, add one on aarch64, clean up priorities This adds new variant test suites for several of the base tests to run them on Cloud disk images. We can't re-use the existing test suites because they have `START_AFTER_TEST` defined and there's no viable way to undefine it (there are things you can do to override the value, but you can't just unset it). Also add a stray test we weren't running on aarch64, and correct some priorities. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-06-17 22:18:21 +00:00
"fedora-Silverblue-dvd_ostree-iso-ppc64le-*-ppc64le": 50,
"fedora-Silverblue-dvd_ostree-iso-x86_64-*-64bit": 50,
"fedora-Workstation-live-iso-ppc64le-*-ppc64le": 40,
Enable more base tests on aarch64 images, fix up priorities a bit Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:57:24 +00:00
"fedora-Workstation-live-iso-x86_64-*-64bit": 40,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Workstation-live_osbuild-iso-x86_64-*-64bit": 70,
Rename tests and flavours as per review.
2021-12-07 10:30:21 +00:00
"fedora-Workstation-upgrade-x86_64-*-64bit": 40,
"fedora-Workstation-upgrade-aarch64-*-aarch64": 40,
Enable more base tests on aarch64 images, fix up priorities a bit Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:57:24 +00:00
"fedora-Workstation-raw_xz-raw.xz-aarch64-*-aarch64": 42
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
base tests: run on Cloud, add one on aarch64, clean up priorities This adds new variant test suites for several of the base tests to run them on Cloud disk images. We can't re-use the existing test suites because they have `START_AFTER_TEST` defined and there's no viable way to undefine it (there are things you can do to override the value, but you can't just unset it). Also add a stray test we weren't running on aarch64, and correct some priorities. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-06-17 22:18:21 +00:00
"POSTINSTALL": "base_service_manipulation",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"ROOT_PASSWORD": "weakpassword",
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"USER_LOGIN": "false"
}
},
"cloud_autocloud": {
"profiles": {
"fedora-Cloud_Base-qcow2-qcow2-aarch64-*-aarch64": 30,
"fedora-Cloud_Base-qcow2-qcow2-ppc64le-*-ppc64le": 30,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Cloud_Base-qcow2-qcow2-x86_64-*-64bit": 30
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"POSTINSTALL": "autocloud"
}
},
Finish the post review changes.
2020-05-28 09:40:34 +00:00
"install_blivet_resize_lvm": {
Add to templates.
2020-05-11 13:55:16 +00:00
"profiles": {
Move install_blivet_resize_lvm, fix install_resize_lvm (#201) This is the same thing we did for install_resize_lvm, to address issue #201. We just didn't get around to doing it for the blivet test yet. We also change the HDDSIZEGB for the parent test to 15GB so the resizing stuff actually works in both resize tests; ever since we changed this the install_resize_lvm test has not been working properly, it hasn't actually been doing any resize. Also drop the swap partition stuff from that test as it's for sure no longer needed. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2021-04-29 23:07:19 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 40,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 40,
"fedora-Server-dvd-iso-x86_64-*-64bit": 40
Add to templates.
2020-05-11 13:55:16 +00:00
},
"settings": {
Finish the post review changes.
2020-05-28 09:40:34 +00:00
"PARTITIONING": "custom_blivet_resize_lvm",
Move install_blivet_resize_lvm, fix install_resize_lvm (#201) This is the same thing we did for install_resize_lvm, to address issue #201. We just didn't get around to doing it for the blivet test yet. We also change the HDDSIZEGB for the parent test to 15GB so the resizing stuff actually works in both resize tests; ever since we changed this the install_resize_lvm test has not been working properly, it hasn't actually been doing any resize. Also drop the swap partition stuff from that test as it's for sure no longer needed. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2021-04-29 23:07:19 +00:00
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
Put INSTALL variable back for LVM resize tests These actually *do* need it because they have START_AFTER_TEST set, but they're still install tests. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-12-13 20:25:38 +00:00
"INSTALL": "1",
Correct postinstall test name for install_blivet_resize_lvm Signed-off-by: Adam Williamson <awilliam@redhat.com>
2021-07-06 17:56:16 +00:00
"POSTINSTALL": "disk_custom_resize_lvm_postinstall",
Add to templates.
2020-05-11 13:55:16 +00:00
"ROOT_PASSWORD": "weakpassword",
Move install_blivet_resize_lvm, fix install_resize_lvm (#201) This is the same thing we did for install_resize_lvm, to address issue #201. We just didn't get around to doing it for the blivet test yet. We also change the HDDSIZEGB for the parent test to 15GB so the resizing stuff actually works in both resize tests; ever since we changed this the install_resize_lvm test has not been working properly, it hasn't actually been doing any resize. Also drop the swap partition stuff from that test as it's for sure no longer needed. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2021-04-29 23:07:19 +00:00
"START_AFTER_TEST": "install_lvm_ext4"
Add to templates.
2020-05-11 13:55:16 +00:00
}
},
Finish the post review changes.
2020-05-28 09:40:34 +00:00
"install_resize_lvm": {
Add to templates.
2020-05-11 13:55:16 +00:00
"profiles": {
Add an installation test using LVM partitioning as asset for resize tests. When Fedora went to BTRFS as a default, we lost the LVM based image to run LVM resize tests with. This PR introduces the `install_lvm.pm` installation test that creates an LVM based qcow2 image to be used by follow-up tests.
2020-11-18 12:44:05 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 40,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 40,
"fedora-Server-dvd-iso-x86_64-*-64bit": 40
Add to templates.
2020-05-11 13:55:16 +00:00
},
"settings": {
Finish the post review changes.
2020-05-28 09:40:34 +00:00
"PARTITIONING": "custom_resize_lvm",
Add an installation test using LVM partitioning as asset for resize tests. When Fedora went to BTRFS as a default, we lost the LVM based image to run LVM resize tests with. This PR introduces the `install_lvm.pm` installation test that creates an LVM based qcow2 image to be used by follow-up tests.
2020-11-18 12:44:05 +00:00
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
Put INSTALL variable back for LVM resize tests These actually *do* need it because they have START_AFTER_TEST set, but they're still install tests. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-12-13 20:25:38 +00:00
"INSTALL": "1",
Add an installation test using LVM partitioning as asset for resize tests. When Fedora went to BTRFS as a default, we lost the LVM based image to run LVM resize tests with. This PR introduces the `install_lvm.pm` installation test that creates an LVM based qcow2 image to be used by follow-up tests.
2020-11-18 12:44:05 +00:00
"ROOT_PASSWORD": "weakpassword",
"START_AFTER_TEST": "install_lvm_ext4"
Add to templates.
2020-05-11 13:55:16 +00:00
}
},
Enable several desktop tests on Workstation aarch64 disk image Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-11-03 00:34:43 +00:00
"desktop_background": {
"profiles": {
"fedora-KDE-live-iso-x86_64-*-64bit": 22,
"fedora-Silverblue-dvd_ostree-iso-ppc64le-*-ppc64le": 50,
"fedora-Silverblue-dvd_ostree-iso-x86_64-*-64bit": 50,
"fedora-Workstation-live-iso-ppc64le-*-ppc64le": 20,
"fedora-Workstation-live-iso-x86_64-*-64bit": 20,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Workstation-live_osbuild-iso-x86_64-*-64bit": 70,
Rename tests and flavours as per review.
2021-12-07 10:30:21 +00:00
"fedora-Workstation-upgrade-x86_64-*-64bit": 40,
"fedora-Workstation-upgrade-aarch64-*-aarch64": 40,
Enable several desktop tests on Workstation aarch64 disk image Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-11-03 00:34:43 +00:00
"fedora-Workstation-raw_xz-raw.xz-aarch64-*-aarch64": 22
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"POSTINSTALL": "desktop_background",
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%"
}
},
"desktop_login": {
"profiles": {
"fedora-KDE-live-iso-x86_64-*-64bit": 30,
"fedora-Workstation-live-iso-x86_64-*-64bit": 30,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Workstation-live_osbuild-iso-x86_64-*-64bit": 70,
Rename tests and flavours as per review.
2021-12-07 10:30:21 +00:00
"fedora-Workstation-upgrade-x86_64-*-64bit": 40,
Enable several desktop tests on Workstation aarch64 disk image Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-11-03 00:34:43 +00:00
"fedora-Workstation-live-iso-ppc64le-*-ppc64le": 30
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"POSTINSTALL": "desktop_login",
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%"
}
},
Add a fingerprint login test (GNOME only) (#223) This adds a test for fingerprint-based login, as requested by @benzea in #223. We use the fprintd dummy device to let us simulate scanning a fingerprint, and check various scenarios recommended by @benzea. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2021-07-22 20:11:56 +00:00
"desktop_fprint": {
"profiles": {
"fedora-Workstation-live-iso-x86_64-*-64bit": 50,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Workstation-live_osbuild-iso-x86_64-*-64bit": 70,
Rename tests and flavours as per review.
2021-12-07 10:30:21 +00:00
"fedora-Workstation-upgrade-x86_64-*-64bit": 40,
Add a fingerprint login test (GNOME only) (#223) This adds a test for fingerprint-based login, as requested by @benzea in #223. We use the fprintd dummy device to let us simulate scanning a fingerprint, and check various scenarios recommended by @benzea. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2021-07-22 20:11:56 +00:00
"fedora-Workstation-live-iso-ppc64le-*-ppc64le": 50
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"POSTINSTALL": "desktop_fprint",
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%"
}
},
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"desktop_browser": {
"profiles": {
"fedora-KDE-live-iso-x86_64-*-64bit": 22,
"fedora-Silverblue-dvd_ostree-iso-ppc64le-*-ppc64le": 50,
"fedora-Silverblue-dvd_ostree-iso-x86_64-*-64bit": 50,
"fedora-Workstation-live-iso-ppc64le-*-ppc64le": 20,
Enable several desktop tests on Workstation aarch64 disk image Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-11-03 00:34:43 +00:00
"fedora-Workstation-live-iso-x86_64-*-64bit": 20,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Workstation-live_osbuild-iso-x86_64-*-64bit": 70,
Rename tests and flavours as per review.
2021-12-07 10:30:21 +00:00
"fedora-Workstation-upgrade-x86_64-*-64bit": 40,
"fedora-Workstation-upgrade-aarch64-*-aarch64": 40,
Enable several desktop tests on Workstation aarch64 disk image Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-11-03 00:34:43 +00:00
"fedora-Workstation-raw_xz-raw.xz-aarch64-*-aarch64": 22
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"POSTINSTALL": "desktop_browser",
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%"
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
}
},
"desktop_notifications_live": {
"profiles": {
"fedora-KDE-live-iso-x86_64-*-64bit": 32,
"fedora-Workstation-live-iso-ppc64le-*-ppc64le": 30,
Add tests for the Workstation live osbuild image We should test this image to make sure it works as well as the official image. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-02-21 00:06:40 +00:00
"fedora-Workstation-live-iso-x86_64-*-64bit": 30,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Workstation-live_osbuild-iso-x86_64-*-64bit": 70
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"ENTRYPOINT": "desktop_notifications"
}
},
"desktop_notifications_postinstall": {
"profiles": {
"fedora-KDE-live-iso-x86_64-*-64bit": 32,
"fedora-Workstation-live-iso-ppc64le-*-ppc64le": 30,
Rename tests and flavours as per review.
2021-12-07 10:30:21 +00:00
"fedora-Workstation-upgrade-x86_64-*-64bit": 40,
Add tests for the Workstation live osbuild image We should test this image to make sure it works as well as the official image. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-02-21 00:06:40 +00:00
"fedora-Workstation-live-iso-x86_64-*-64bit": 30,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Workstation-live_osbuild-iso-x86_64-*-64bit": 70
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"BOOTFROM": "c",
"ENTRYPOINT": "desktop_notifications",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%"
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
}
},
Rename desktop_printing_cups back to desktop_printing It's best to keep the test name consistent unless we *really* have to change it; that way the "past runs" history in openQA still works and the name doesn't change in resultsdb and CI messages. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-02-10 17:35:50 +00:00
"desktop_printing": {
Modify Desktop Printing test to use two different methods. The PR introduces an improved logic to the desktop_printing.pm that allows to use the USE_CUPS variable in templates to trigger the installation of cups-pdf prior to the actual test. The cups-pdf is then used as an alternative PDF printer instead the built-in Save As PDF method.
2022-02-08 08:57:27 +00:00
"profiles": {
"fedora-KDE-live-iso-x86_64-*-64bit": 20,
"fedora-Workstation-live-iso-ppc64le-*-ppc64le": 20,
"fedora-Workstation-live-iso-x86_64-*-64bit": 20,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Workstation-live_osbuild-iso-x86_64-*-64bit": 70,
Modify Desktop Printing test to use two different methods. The PR introduces an improved logic to the desktop_printing.pm that allows to use the USE_CUPS variable in templates to trigger the installation of cups-pdf prior to the actual test. The cups-pdf is then used as an alternative PDF printer instead the built-in Save As PDF method.
2022-02-08 08:57:27 +00:00
"fedora-Workstation-upgrade-x86_64-*-64bit": 40,
"fedora-Workstation-upgrade-aarch64-*-aarch64": 40,
"fedora-Workstation-raw_xz-raw.xz-aarch64-*-aarch64": 22
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
Add a space to USE_CUPS in templates to match style Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-02-10 17:33:15 +00:00
"USE_CUPS": "1",
Modify Desktop Printing test to use two different methods. The PR introduces an improved logic to the desktop_printing.pm that allows to use the USE_CUPS variable in templates to trigger the installation of cups-pdf prior to the actual test. The cups-pdf is then used as an alternative PDF printer instead the built-in Save As PDF method.
2022-02-08 08:57:27 +00:00
"POSTINSTALL": "desktop_printing",
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%"
}
},
Rename desktop_printing_cups back to desktop_printing It's best to keep the test name consistent unless we *really* have to change it; that way the "past runs" history in openQA still works and the name doesn't change in resultsdb and CI messages. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-02-10 17:35:50 +00:00
"desktop_printing_builtin": {
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"profiles": {
"fedora-KDE-live-iso-x86_64-*-64bit": 20,
"fedora-Workstation-live-iso-ppc64le-*-ppc64le": 20,
Enable several desktop tests on Workstation aarch64 disk image Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-11-03 00:34:43 +00:00
"fedora-Workstation-live-iso-x86_64-*-64bit": 20,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Workstation-live_osbuild-iso-x86_64-*-64bit": 70,
Rename tests and flavours as per review.
2021-12-07 10:30:21 +00:00
"fedora-Workstation-upgrade-x86_64-*-64bit": 40,
"fedora-Workstation-upgrade-aarch64-*-aarch64": 40,
Enable several desktop tests on Workstation aarch64 disk image Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-11-03 00:34:43 +00:00
"fedora-Workstation-raw_xz-raw.xz-aarch64-*-aarch64": 22
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"POSTINSTALL": "desktop_printing",
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%"
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
}
},
"desktop_terminal": {
"profiles": {
"fedora-KDE-live-iso-x86_64-*-64bit": 22,
"fedora-Silverblue-dvd_ostree-iso-ppc64le-*-ppc64le": 50,
"fedora-Silverblue-dvd_ostree-iso-x86_64-*-64bit": 50,
"fedora-Workstation-live-iso-ppc64le-*-ppc64le": 20,
Enable several desktop tests on Workstation aarch64 disk image Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-11-03 00:34:43 +00:00
"fedora-Workstation-live-iso-x86_64-*-64bit": 20,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Workstation-live_osbuild-iso-x86_64-*-64bit": 70,
Rename tests and flavours as per review.
2021-12-07 10:30:21 +00:00
"fedora-Workstation-upgrade-x86_64-*-64bit": 40,
"fedora-Workstation-upgrade-aarch64-*-aarch64": 40,
Enable several desktop tests on Workstation aarch64 disk image Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-11-03 00:34:43 +00:00
"fedora-Workstation-raw_xz-raw.xz-aarch64-*-aarch64": 22
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"POSTINSTALL": "desktop_terminal",
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%"
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
}
},
Create a test suite for Evince. This PR fixes issue #188. It adds a test suite to test basic functionality of Evince and brings the following features: * test scripts for various Evince functions. * needles to support the Evince test scripts * new template variables `TESTPATH` and `POSTINSTALL_LOAD_ALL` (see below) * new logic in `main.py` (see below) The new variables and the new logic make it easier to create test suites for post-installation tests. If TESTPATH is used, OpenQA will take all tests mentioned in POSTINSTALL from that specified TESTPATH. If both TESTPATH and POSTINSTALL_LOAD_ALL are used, then OpenQA will run all tests it can find at the TESTPATH location. If POSTINSTALL and POSTINSTALL_LOAD_ALL are set simultaneously, then only POSTINSTALL will be taken into account and OpenQA will only load tests mentioned there.
2021-07-14 16:04:16 +00:00
"evince": {
"profiles": {
"fedora-Silverblue-dvd_ostree-iso-ppc64le-*-ppc64le": 50,
"fedora-Silverblue-dvd_ostree-iso-x86_64-*-64bit": 50,
"fedora-Workstation-live-iso-ppc64le-*-ppc64le": 20,
"fedora-Workstation-live-iso-x86_64-*-64bit": 20,
Rename tests and flavours as per review.
2021-12-07 10:30:21 +00:00
"fedora-Workstation-upgrade-x86_64-*-64bit": 40,
"fedora-Workstation-upgrade-aarch64-*-aarch64": 40,
Create a test suite for Evince. This PR fixes issue #188. It adds a test suite to test basic functionality of Evince and brings the following features: * test scripts for various Evince functions. * needles to support the Evince test scripts * new template variables `TESTPATH` and `POSTINSTALL_LOAD_ALL` (see below) * new logic in `main.py` (see below) The new variables and the new logic make it easier to create test suites for post-installation tests. If TESTPATH is used, OpenQA will take all tests mentioned in POSTINSTALL from that specified TESTPATH. If both TESTPATH and POSTINSTALL_LOAD_ALL are used, then OpenQA will run all tests it can find at the TESTPATH location. If POSTINSTALL and POSTINSTALL_LOAD_ALL are set simultaneously, then only POSTINSTALL will be taken into account and OpenQA will only load tests mentioned there.
2021-07-14 16:04:16 +00:00
"fedora-Workstation-raw_xz-raw.xz-aarch64-*-aarch64": 22
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"POSTINSTALL_PATH": "tests/applications/evince",
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%"
}
},
Add a new test for Calculator.
2022-07-13 11:11:18 +00:00
"calculator": {
"profiles": {
"fedora-Silverblue-dvd_ostree-iso-ppc64le-*-ppc64le": 50,
"fedora-Silverblue-dvd_ostree-iso-x86_64-*-64bit": 50,
"fedora-Workstation-live-iso-ppc64le-*-ppc64le": 20,
"fedora-Workstation-live-iso-x86_64-*-64bit": 20,
"fedora-Workstation-upgrade-x86_64-*-64bit": 40,
"fedora-Workstation-upgrade-aarch64-*-aarch64": 40,
"fedora-Workstation-raw_xz-raw.xz-aarch64-*-aarch64": 22
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"POSTINSTALL_PATH": "tests/applications/calculator",
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%"
}
},
Create tests for Clocks.
2022-06-17 08:01:31 +00:00
"clocks": {
"profiles": {
"fedora-Silverblue-dvd_ostree-iso-ppc64le-*-ppc64le": 50,
"fedora-Silverblue-dvd_ostree-iso-x86_64-*-64bit": 50,
"fedora-Workstation-live-iso-ppc64le-*-ppc64le": 20,
"fedora-Workstation-live-iso-x86_64-*-64bit": 20,
Create a test suite for Disks.
2023-01-04 14:01:36 +00:00
"fedora-Workstation-upgrade-x86_64-*-64bit": 40,
Create tests for Clocks.
2022-06-17 08:01:31 +00:00
"fedora-Workstation-upgrade-aarch64-*-aarch64": 40,
"fedora-Workstation-raw_xz-raw.xz-aarch64-*-aarch64": 22
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"POSTINSTALL_PATH": "tests/applications/clocks",
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%"
}
},
Create a test case for Archiver.
2022-09-12 07:38:09 +00:00
"archiver": {
"profiles": {
"fedora-Silverblue-dvd_ostree-iso-ppc64le-*-ppc64le": 50,
"fedora-Silverblue-dvd_ostree-iso-x86_64-*-64bit": 50,
"fedora-Workstation-live-iso-ppc64le-*-ppc64le": 20,
"fedora-Workstation-live-iso-x86_64-*-64bit": 20,
Create a test suite for Disks.
2023-01-04 14:01:36 +00:00
"fedora-Workstation-upgrade-x86_64-*-64bit": 40,
Create a test case for Archiver.
2022-09-12 07:38:09 +00:00
"fedora-Workstation-upgrade-aarch64-*-aarch64": 40,
"fedora-Workstation-raw_xz-raw.xz-aarch64-*-aarch64": 22
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"POSTINSTALL_PATH": "tests/applications/archiver",
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%"
}
},
Create tests for Gnome Contacts.
2022-07-25 09:34:20 +00:00
"contacts": {
"profiles": {
"fedora-Silverblue-dvd_ostree-iso-ppc64le-*-ppc64le": 50,
"fedora-Silverblue-dvd_ostree-iso-x86_64-*-64bit": 50,
"fedora-Workstation-live-iso-ppc64le-*-ppc64le": 20,
"fedora-Workstation-live-iso-x86_64-*-64bit": 20,
Create a test suite for Disks.
2023-01-04 14:01:36 +00:00
"fedora-Workstation-upgrade-x86_64-*-64bit": 40,
Create tests for Gnome Contacts.
2022-07-25 09:34:20 +00:00
"fedora-Workstation-upgrade-aarch64-*-aarch64": 40,
"fedora-Workstation-raw_xz-raw.xz-aarch64-*-aarch64": 22
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"POSTINSTALL_PATH": "tests/applications/contacts",
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%"
}
},
Add new test for Characters. This PR adds a small test suite to test the Characters applications. It displays several different groups of characters and then tries to copy one of the characters and place it into a text editor.
2023-01-03 14:04:20 +00:00
"characters": {
"profiles": {
"fedora-Silverblue-dvd_ostree-iso-ppc64le-*-ppc64le": 50,
"fedora-Silverblue-dvd_ostree-iso-x86_64-*-64bit": 50,
"fedora-Workstation-live-iso-ppc64le-*-ppc64le": 20,
"fedora-Workstation-live-iso-x86_64-*-64bit": 20,
Create a test suite for Disks.
2023-01-04 14:01:36 +00:00
"fedora-Workstation-upgrade-x86_64-*-64bit": 40,
Add new test for Characters. This PR adds a small test suite to test the Characters applications. It displays several different groups of characters and then tries to copy one of the characters and place it into a text editor.
2023-01-03 14:04:20 +00:00
"fedora-Workstation-upgrade-aarch64-*-aarch64": 40,
"fedora-Workstation-raw_xz-raw.xz-aarch64-*-aarch64": 22
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"POSTINSTALL_PATH": "tests/applications/characters",
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%"
}
},
Create a test suite for Disks.
2023-01-04 14:01:36 +00:00
"disks": {
"profiles": {
"fedora-Silverblue-dvd_ostree-iso-ppc64le-*-ppc64le": 50,
"fedora-Silverblue-dvd_ostree-iso-x86_64-*-64bit": 50,
"fedora-Workstation-live-iso-ppc64le-*-ppc64le": 20,
"fedora-Workstation-live-iso-x86_64-*-64bit": 20,
"fedora-Workstation-upgrade-x86_64-*-64bit": 40,
"fedora-Workstation-upgrade-aarch64-*-aarch64": 40,
"fedora-Workstation-raw_xz-raw.xz-aarch64-*-aarch64": 22
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"POSTINSTALL_PATH": "tests/applications/disks",
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%"
}
},
Create test suite for Fonts.
2023-01-24 12:48:52 +00:00
"fonts": {
"profiles": {
"fedora-Silverblue-dvd_ostree-iso-ppc64le-*-ppc64le": 50,
"fedora-Silverblue-dvd_ostree-iso-x86_64-*-64bit": 50,
"fedora-Workstation-live-iso-ppc64le-*-ppc64le": 20,
"fedora-Workstation-live-iso-x86_64-*-64bit": 20,
"fedora-Workstation-upgrade-aarch64-*-aarch64": 40,
"fedora-Workstation-raw_xz-raw.xz-aarch64-*-aarch64": 22
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"POSTINSTALL_PATH": "tests/applications/fonts",
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%"
}
},
Create a test for basic Flatpak operations. This PR tries to respond to issue #294. On Silverblue, this will try: * flatpak install * flatpak remote-add * flatpak list * flatpak remotes * flatpak remove * flatpak update and also it tests that a flatpak can be built.
2023-09-12 12:54:56 +00:00
"flatpak": {
"profiles": {
"fedora-Silverblue-dvd_ostree-iso-ppc64le-*-ppc64le": 50,
"fedora-Silverblue-dvd_ostree-iso-x86_64-*-64bit": 50
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"POSTINSTALL": "flatpak_fedora flatpak_flathub flatpak_update",
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%"
}
},
Create a test for Gnome Panel.
2022-10-13 13:01:53 +00:00
"gnome-panel": {
"profiles": {
"fedora-Silverblue-dvd_ostree-iso-ppc64le-*-ppc64le": 50,
"fedora-Silverblue-dvd_ostree-iso-x86_64-*-64bit": 50,
"fedora-Workstation-live-iso-ppc64le-*-ppc64le": 20,
"fedora-Workstation-live-iso-x86_64-*-64bit": 20,
"fedora-Workstation-upgrade-aarch64-*-aarch64": 40,
"fedora-Workstation-raw_xz-raw.xz-aarch64-*-aarch64": 22
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"POSTINSTALL_PATH": "tests/applications/gnome-panel",
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%"
}
},
Create tests for Help.
2022-06-20 12:44:56 +00:00
"help_viewer": {
"profiles": {
"fedora-Silverblue-dvd_ostree-iso-ppc64le-*-ppc64le": 50,
"fedora-Silverblue-dvd_ostree-iso-x86_64-*-64bit": 50,
"fedora-Workstation-live-iso-ppc64le-*-ppc64le": 20,
"fedora-Workstation-live-iso-x86_64-*-64bit": 20,
"fedora-Workstation-upgrade-x86_64-*-64bit": 40,
"fedora-Workstation-upgrade-aarch64-*-aarch64": 40,
"fedora-Workstation-raw_xz-raw.xz-aarch64-*-aarch64": 22
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"POSTINSTALL_PATH": "tests/applications/help",
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%"
}
},
Create test suite for Maps.
2022-09-27 17:54:40 +00:00
"maps": {
"profiles": {
"fedora-Silverblue-dvd_ostree-iso-ppc64le-*-ppc64le": 50,
"fedora-Silverblue-dvd_ostree-iso-x86_64-*-64bit": 50,
"fedora-Workstation-live-iso-ppc64le-*-ppc64le": 20,
"fedora-Workstation-live-iso-x86_64-*-64bit": 20,
"fedora-Workstation-upgrade-x86_64-*-64bit": 40,
"fedora-Workstation-upgrade-aarch64-*-aarch64": 40,
"fedora-Workstation-raw_xz-raw.xz-aarch64-*-aarch64": 22
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"POSTINSTALL_PATH": "tests/applications/maps",
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%"
}
},
Create a test suite for Nautilus.
2022-02-10 09:29:17 +00:00
"nautilus": {
"profiles": {
"fedora-Silverblue-dvd_ostree-iso-ppc64le-*-ppc64le": 50,
"fedora-Silverblue-dvd_ostree-iso-x86_64-*-64bit": 50,
"fedora-Workstation-live-iso-ppc64le-*-ppc64le": 20,
"fedora-Workstation-live-iso-x86_64-*-64bit": 20,
"fedora-Workstation-upgrade-x86_64-*-64bit": 40,
"fedora-Workstation-upgrade-aarch64-*-aarch64": 40,
"fedora-Workstation-raw_xz-raw.xz-aarch64-*-aarch64": 22
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"POSTINSTALL_PATH": "tests/applications/nautilus",
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%"
}
},
Add a 'navigation' test for GNOME. This PR partly solves the issue #301 when it adds the navigation testing for Gnome. It uses the keyboard combinations to cycle through running applications and checks that applications could be switched accordingly. It also tests that you can switch between workspaces and that you can move an applications to another workspace.
2023-08-28 09:27:11 +00:00
"navigation": {
"profiles": {
"fedora-Silverblue-dvd_ostree-iso-ppc64le-*-ppc64le": 50,
"fedora-Silverblue-dvd_ostree-iso-x86_64-*-64bit": 50,
"fedora-Workstation-live-iso-ppc64le-*-ppc64le": 20,
"fedora-Workstation-live-iso-x86_64-*-64bit": 20,
"fedora-Workstation-upgrade-x86_64-*-64bit": 40,
"fedora-Workstation-upgrade-aarch64-*-aarch64": 40,
"fedora-Workstation-raw_xz-raw.xz-aarch64-*-aarch64": 22
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"POSTINSTALL_PATH": "tests/applications/navigation",
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%"
}
},
Create a test suite for Gnome Text Editor
2022-01-25 13:45:38 +00:00
"gnome_text_editor": {
"profiles": {
"fedora-Silverblue-dvd_ostree-iso-ppc64le-*-ppc64le": 50,
"fedora-Silverblue-dvd_ostree-iso-x86_64-*-64bit": 50,
"fedora-Workstation-live-iso-ppc64le-*-ppc64le": 20,
"fedora-Workstation-live-iso-x86_64-*-64bit": 20,
"fedora-Workstation-upgrade-x86_64-*-64bit": 40,
"fedora-Workstation-upgrade-aarch64-*-aarch64": 40,
"fedora-Workstation-raw_xz-raw.xz-aarch64-*-aarch64": 22
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"POSTINSTALL_PATH": "tests/applications/gnome-text-editor",
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%"
Create a new test for Gnome Weather
2022-07-21 11:55:38 +00:00
}
},
Create the test for system monitor.
2022-09-21 12:16:58 +00:00
"sysmon": {
"profiles": {
"fedora-Silverblue-dvd_ostree-iso-ppc64le-*-ppc64le": 50,
"fedora-Silverblue-dvd_ostree-iso-x86_64-*-64bit": 50,
"fedora-Workstation-live-iso-ppc64le-*-ppc64le": 20,
"fedora-Workstation-live-iso-x86_64-*-64bit": 20,
"fedora-Workstation-upgrade-aarch64-*-aarch64": 40,
"fedora-Workstation-raw_xz-raw.xz-aarch64-*-aarch64": 22
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"POSTINSTALL_PATH": "tests/applications/sysmon",
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%"
}
},
Create test for the Tour application.
2023-06-19 09:36:42 +00:00
"tour": {
"profiles": {
"fedora-Silverblue-dvd_ostree-iso-ppc64le-*-ppc64le": 50,
"fedora-Silverblue-dvd_ostree-iso-x86_64-*-64bit": 50,
"fedora-Workstation-live-iso-ppc64le-*-ppc64le": 20,
"fedora-Workstation-live-iso-x86_64-*-64bit": 20,
"fedora-Workstation-upgrade-x86_64-*-64bit": 40,
"fedora-Workstation-upgrade-aarch64-*-aarch64": 40,
"fedora-Workstation-raw_xz-raw.xz-aarch64-*-aarch64": 22
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"POSTINSTALL_PATH": "tests/applications/tour",
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%"
}
},
Create a new test for Gnome Weather
2022-07-21 11:55:38 +00:00
"weather": {
"profiles": {
"fedora-Silverblue-dvd_ostree-iso-ppc64le-*-ppc64le": 50,
"fedora-Silverblue-dvd_ostree-iso-x86_64-*-64bit": 50,
"fedora-Workstation-live-iso-ppc64le-*-ppc64le": 20,
"fedora-Workstation-live-iso-x86_64-*-64bit": 20,
"fedora-Workstation-upgrade-aarch64-*-aarch64": 40,
"fedora-Workstation-raw_xz-raw.xz-aarch64-*-aarch64": 22
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"POSTINSTALL_PATH": "tests/applications/weather",
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%"
Create a test suite for Gnome Text Editor
2022-01-25 13:45:38 +00:00
}
},
Create a test suite for Loupe (Image Viewer) This PR adds a test for a new Image Viewer called Loupe. It is based on the old Image Viewer test, newly reneedled with some of the tests shortened, deleted or edited as the new Image Viewer has a little bit less functions compared to the previous one. Add needles.
2021-08-10 11:50:19 +00:00
"loupe": {
"profiles": {
"fedora-Workstation-live-iso-ppc64le-*-ppc64le": 20,
"fedora-Workstation-live-iso-x86_64-*-64bit": 20,
"fedora-Workstation-raw_xz-raw.xz-aarch64-*-aarch64": 22
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"POSTINSTALL_PATH": "tests/applications/loupe",
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%"
}
},
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"desktop_update_graphical": {
"profiles": {
"fedora-KDE-live-iso-x86_64-*-64bit": 32,
"fedora-Workstation-live-iso-ppc64le-*-ppc64le": 30,
Enable several desktop tests on Workstation aarch64 disk image Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-11-03 00:34:43 +00:00
"fedora-Workstation-live-iso-x86_64-*-64bit": 30,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Workstation-live_osbuild-iso-x86_64-*-64bit": 70,
Rename tests and flavours as per review.
2021-12-07 10:30:21 +00:00
"fedora-Workstation-upgrade-x86_64-*-64bit": 40,
"fedora-Workstation-upgrade-aarch64-*-aarch64": 40,
Enable several desktop tests on Workstation aarch64 disk image Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-11-03 00:34:43 +00:00
"fedora-Workstation-raw_xz-raw.xz-aarch64-*-aarch64": 32
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"POSTINSTALL": "desktop_update_graphical",
desktop_update_graphical: try to workaround GGO #2442 In current F40 and Rawhide, this test is frequently failing because gnome-software is behaving weirdly at startup - the third-party software dialog moves around even more than before, the app seems to get stuck in the "not responding" state briefly sometimes, and there's a very weird state it gets into sometimes where the window is shorter than usual and clicks don't seem to register in the right place. While I'm trying to bisect these bugs, these magic voodoo incantations (tested on the staging instance) seem to mostly work around the weird behaviour, and setting RETRY=2 should backstop it a bit further. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-02-16 20:50:05 +00:00
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%",
"RETRY": 2
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
}
},
"install_anaconda_text": {
"profiles": {
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 20,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 20,
"fedora-Server-dvd-iso-x86_64-*-64bit": 20
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"ANACONDA_TEXT": "1"
}
},
Automate the Anaconda_Save_Traceback_to_Bugzilla_Text test case. This PR adds a new test that automates the above mentioned test case. It starts the installation in text mode using the `install_text` test case, which it interrupts using the Anaconda crash trigger. When the crash happens, it goes through the process of reporting the bug to Bugzilla, checks that Bugzilla sends a positive confirmation of the action, but also performs some REST API calls to do a proper check and then it closes the bug to clean up.
2021-04-27 11:02:53 +00:00
"install_anaconda_text_save_traceback_bugzilla": {
"profiles": {
"fedora-seasonal-aarch64-*-aarch64": 20,
"fedora-seasonal-ppc64le-*-ppc64le": 20,
"fedora-seasonal-x86_64-*-64bit": 20
},
"settings": {
"ANACONDA_TEXT": "1",
"CRASH_REPORT": "1"
}
},
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"install_arabic_language": {
"profiles": {
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 40,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 40,
"fedora-Server-dvd-iso-x86_64-*-64bit": 40
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"DESKTOP": "gnome",
"ENCRYPT_PASSWORD": "weakpassword",
Increase HDD size from 13 to 15G for language tests because failing in "disk_guided_empty" module at least for PowerPC. Signed-off-by: Guy Menanteau <menantea@linux.vnet.ibm.com>
2020-02-26 10:32:48 +00:00
"HDDSIZEGB": "15",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"LANGUAGE": "arabic",
"PACKAGE_SET": "workstation",
"POSTINSTALL": "_console_login",
"QEMU_DISABLE_SNAPSHOTS": "1",
"REPOSITORY_VARIATION": "%LOCATION%",
"ROOT_PASSWORD": "weakpassword",
"SWITCHED_LAYOUT": "1",
"USER_LOGIN": "qwerty"
}
},
"install_arm_image_deployment_upload": {
"profiles": {
Enable aarch64 disk image testing, related fixes This sets us up to test the release-blocking aarch64 disk images (Minimal, Server and Workstation). It also allows for testing armhfp disk images on aarch64 worker hosts (though my testing of that isn't going too well so far), and fixes the initial-setup handling for a change upstream ('use password' is now the default so we don't need to choose it). We rewire disk image deployment test loading to work through the generic loader code rather than using ENTRYPOINT, as it allows us to more gracefully handle graphical (Workstation) vs. console (Server, Minimal), moving the code for handling console initial-setup to a helper function just like the code for gnome-initial-setup and having _console_ wait_login call it when appropriate. We also tweak desktop_vt a bit because now we need to switch from a console running as test to a desktop, which breaks the assumption that the highest numbered session of user test is the desktop... Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-28 21:20:16 +00:00
"fedora-Minimal-raw_xz-raw.xz-aarch64-*-aarch64": 12,
"fedora-Server-raw_xz-raw.xz-aarch64-*-aarch64": 12,
"fedora-Workstation-raw_xz-raw.xz-aarch64-*-aarch64": 12
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
Enable aarch64 disk image testing, related fixes This sets us up to test the release-blocking aarch64 disk images (Minimal, Server and Workstation). It also allows for testing armhfp disk images on aarch64 worker hosts (though my testing of that isn't going too well so far), and fixes the initial-setup handling for a change upstream ('use password' is now the default so we don't need to choose it). We rewire disk image deployment test loading to work through the generic loader code rather than using ENTRYPOINT, as it allows us to more gracefully handle graphical (Workstation) vs. console (Server, Minimal), moving the code for handling console initial-setup to a helper function just like the code for gnome-initial-setup and having _console_ wait_login call it when appropriate. We also tweak desktop_vt a bit because now we need to switch from a console running as test to a desktop, which breaks the assumption that the highest numbered session of user test is the desktop... Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-28 21:20:16 +00:00
"IMAGE_DEPLOY": "1",
"INSTALL_NO_USER": "1",
arm image deploy: don't use HDD_1 Setting HDD_1 to %HDD_2% is broken in recent openQA: https://github.com/os-autoinst/openQA/pull/3309#issuecomment-721906935 I count this as a bug, but we can solve it like this, I think - we don't actually need to set this test up so carefully to only have the disk image as HDD_1 and no HDD_2, we can actually just let the disk image be HDD_2 and have an empty disk as HDD_1 and the test still works, qemu will boot from the second disk and we can upload it and everything's fine. So let's just go with that. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-11-04 19:42:13 +00:00
"NUMDISKS": "2",
"STORE_HDD_2": "disk_%FLAVOR%_%MACHINE%.qcow2"
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
}
},
"install_asian_language": {
"profiles": {
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 40,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 40,
"fedora-Server-dvd-iso-x86_64-*-64bit": 40
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"DESKTOP": "gnome",
"ENCRYPT_PASSWORD": "weakpassword",
Increase HDD size from 13 to 15G for language tests because failing in "disk_guided_empty" module at least for PowerPC. Signed-off-by: Guy Menanteau <menantea@linux.vnet.ibm.com>
2020-02-26 10:32:48 +00:00
"HDDSIZEGB": "15",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"INPUT_METHOD": "1",
"LANGUAGE": "japanese",
"PACKAGE_SET": "workstation",
"POSTINSTALL": "_console_login",
"QEMU_DISABLE_SNAPSHOTS": "1",
"REPOSITORY_VARIATION": "%LOCATION%",
"ROOT_PASSWORD": "weakpassword",
"USER_LOGIN": "qwerty"
}
},
"install_blivet_btrfs": {
"profiles": {
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 40,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 40,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Server-dvd-iso-x86_64-*-bios": 40,
"fedora-Server-dvd-iso-x86_64-*-64bit": 41
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"PARTITIONING": "custom_blivet_btrfs",
"POSTINSTALL": "disk_custom_btrfs_postinstall",
"ROOT_PASSWORD": "weakpassword"
}
},
"install_blivet_lvmthin": {
"profiles": {
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 40,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 40,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Server-dvd-iso-x86_64-*-bios": 40,
"fedora-Server-dvd-iso-x86_64-*-64bit": 41
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"PARTITIONING": "custom_blivet_lvmthin",
"POSTINSTALL": "disk_custom_lvmthin_postinstall",
"ROOT_PASSWORD": "weakpassword"
}
},
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"install_blivet_btrfs_preserve_home_bios": {
Create testcase to recreate Btrfs layout using Blivet and preserve home. This PR uses the Anaconda Blivet partitioning to recreate a partition layout while preserving the content of the /home subvolume. It also adds the postinstall test to check that the home has been preserved.
2020-12-10 12:30:59 +00:00
"profiles": {
Fix blivet preserve_home test templates for UEFI switchover Somehow these two got completely scrambled, testing the wrong things on the wrong images. Fix them to match the non-blivet counterparts, which are correct. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-04-08 19:19:51 +00:00
"fedora-Server-dvd-iso-x86_64-*-bios": 41
Create testcase to recreate Btrfs layout using Blivet and preserve home. This PR uses the Anaconda Blivet partitioning to recreate a partition layout while preserving the content of the /home subvolume. It also adds the postinstall test to check that the home has been preserved.
2020-12-10 12:30:59 +00:00
},
"settings": {
"PARTITIONING": "custom_blivet_btrfs_preserve_home",
Fix blivet preserve_home test templates for UEFI switchover Somehow these two got completely scrambled, testing the wrong things on the wrong images. Fix them to match the non-blivet counterparts, which are correct. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-04-08 19:19:51 +00:00
"HDD_1": "disk_f%CURRREL%_minimal-bios_4_%ARCH%.qcow2",
Create testcase to recreate Btrfs layout using Blivet and preserve home. This PR uses the Anaconda Blivet partitioning to recreate a partition layout while preserving the content of the /home subvolume. It also adds the postinstall test to check that the home has been preserved.
2020-12-10 12:30:59 +00:00
"POSTINSTALL": "btrfs_preserve_home_check_content",
"ROOT_PASSWORD": "weakpassword"
}
},
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"install_blivet_btrfs_preserve_home": {
Create testcase to recreate Btrfs layout using Blivet and preserve home. This PR uses the Anaconda Blivet partitioning to recreate a partition layout while preserving the content of the /home subvolume. It also adds the postinstall test to check that the home has been preserved.
2020-12-10 12:30:59 +00:00
"profiles": {
"fedora-Server-dvd-iso-aarch64-*-aarch64": 40,
Fix blivet preserve_home test templates for UEFI switchover Somehow these two got completely scrambled, testing the wrong things on the wrong images. Fix them to match the non-blivet counterparts, which are correct. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-04-08 19:19:51 +00:00
"fedora-Server-dvd-iso-x86_64-*-64bit": 40
Create testcase to recreate Btrfs layout using Blivet and preserve home. This PR uses the Anaconda Blivet partitioning to recreate a partition layout while preserving the content of the /home subvolume. It also adds the postinstall test to check that the home has been preserved.
2020-12-10 12:30:59 +00:00
},
"settings": {
"PARTITIONING": "custom_blivet_btrfs_preserve_home",
Fix blivet preserve_home test templates for UEFI switchover Somehow these two got completely scrambled, testing the wrong things on the wrong images. Fix them to match the non-blivet counterparts, which are correct. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-04-08 19:19:51 +00:00
"HDD_1": "disk_f%CURRREL%_desktop_5_%ARCH%.qcow2",
Create testcase to recreate Btrfs layout using Blivet and preserve home. This PR uses the Anaconda Blivet partitioning to recreate a partition layout while preserving the content of the /home subvolume. It also adds the postinstall test to check that the home has been preserved.
2020-12-10 12:30:59 +00:00
"POSTINSTALL": "btrfs_preserve_home_check_content",
"ROOT_PASSWORD": "weakpassword"
}
},
Add a new testcase to test creation of LVM with ext4 using Blivet. This PR adds a test that uses the Blivet interface to create an LVM layout with ext4 filesystem as well as a postinstall test that checks that the LVM layout has been created correctly.
2020-12-08 10:14:40 +00:00
"install_blivet_lvm_ext4": {
"profiles": {
"fedora-Server-dvd-iso-aarch64-*-aarch64": 40,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 40,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Server-dvd-iso-x86_64-*-bios": 40,
"fedora-Server-dvd-iso-x86_64-*-64bit": 41
Add a new testcase to test creation of LVM with ext4 using Blivet. This PR adds a test that uses the Blivet interface to create an LVM layout with ext4 filesystem as well as a postinstall test that checks that the LVM layout has been created correctly.
2020-12-08 10:14:40 +00:00
},
"settings": {
"PARTITIONING": "custom_blivet_lvm_ext4",
"POSTINSTALL": "disk_custom_lvm_ext4_postinstall",
"ROOT_PASSWORD": "weakpassword"
}
},
Create Blivet standard partitioning with ext4 testcase. This PR introduces a test case that uses the Blivet partitioning tool to create a standard partitioning layout with / and /boot (and specific partitions for UEFI and ARM64) using ext4 as the selected filesystem. It also adds a postinstallation test to check that the partitions have been created correctly.
2020-12-07 12:33:37 +00:00
"install_blivet_standard_partition_ext4": {
"profiles": {
"fedora-Server-dvd-iso-aarch64-*-aarch64": 40,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 40,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Server-dvd-iso-x86_64-*-bios": 40,
"fedora-Server-dvd-iso-x86_64-*-64bit": 41
Create Blivet standard partitioning with ext4 testcase. This PR introduces a test case that uses the Blivet partitioning tool to create a standard partitioning layout with / and /boot (and specific partitions for UEFI and ARM64) using ext4 as the selected filesystem. It also adds a postinstallation test to check that the partitions have been created correctly.
2020-12-07 12:33:37 +00:00
},
"settings": {
"PARTITIONING": "custom_blivet_standard_partition_ext4",
"ROOT_PASSWORD": "weakpassword"
}
},
Add 'with swap' tests, drop swap parts from other tests (#180) In Fedora 33, we generally no longer include a disk-based swap partition by default (instead swap-on-ZRAM is used, see https://fedoraproject.org/wiki/Changes/SwapOnZRAM ). This tweaks our tests to account for that. In tests that aren't to do with swap at all, we stop including a swap partition in order to be closer to the default layout. We replace the old _no_swap blivet and custom tests with _with_swap tests that, as the name implies, *explicitly include* a swap partition, and adjust the postinstall test to check the disk swap partition is there. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-08-11 20:34:37 +00:00
"install_blivet_with_swap": {
"profiles": {
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 50,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 50,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Server-dvd-iso-x86_64-*-bios": 50,
"fedora-Server-dvd-iso-x86_64-*-64bit": 51
Add 'with swap' tests, drop swap parts from other tests (#180) In Fedora 33, we generally no longer include a disk-based swap partition by default (instead swap-on-ZRAM is used, see https://fedoraproject.org/wiki/Changes/SwapOnZRAM ). This tweaks our tests to account for that. In tests that aren't to do with swap at all, we stop including a swap partition in order to be closer to the default layout. We replace the old _no_swap blivet and custom tests with _with_swap tests that, as the name implies, *explicitly include* a swap partition, and adjust the postinstall test to check the disk swap partition is there. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-08-11 20:34:37 +00:00
},
"settings": {
"PARTITIONING": "custom_blivet_with_swap",
"POSTINSTALL": "disk_custom_with_swap_postinstall",
"ROOT_PASSWORD": "weakpassword"
}
},
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"install_blivet_software_raid": {
"profiles": {
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 40,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 40,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Server-dvd-iso-x86_64-*-bios": 40,
"fedora-Server-dvd-iso-x86_64-*-64bit": 41
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"NUMDISKS": "2",
"PARTITIONING": "custom_blivet_software_raid",
"POSTINSTALL": "disk_custom_software_raid_postinstall",
"ROOT_PASSWORD": "weakpassword"
}
},
"install_blivet_xfs": {
"profiles": {
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 40,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 40,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Server-dvd-iso-x86_64-*-bios": 40,
"fedora-Server-dvd-iso-x86_64-*-64bit": 41
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"PARTITIONING": "custom_blivet_xfs",
"POSTINSTALL": "disk_custom_xfs_postinstall",
"ROOT_PASSWORD": "weakpassword"
}
},
"install_btrfs": {
"profiles": {
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 40,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 40,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Server-dvd-iso-x86_64-*-bios": 40,
"fedora-Server-dvd-iso-x86_64-*-64bit": 41
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"PARTITIONING": "custom_btrfs",
"ROOT_PASSWORD": "weakpassword"
}
},
Add several tests to test QA:Testcase_partitioning_custom_btrfs_preserve_home. This PR adds the `install_btrfs_upload` to install the btrfs based image, the `btrfs_preserve_home_extras` to prepare and test the data on the home partition, as well as the `custom_btrfs_preserve_home` that uses the preinstalled btrfs image and uses its current partitioning to preserve the home partition and the data on it.
2020-11-26 12:37:32 +00:00
"install_btrfs_preserve_home": {
"profiles": {
"fedora-Server-dvd-iso-aarch64-*-aarch64": 10,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 10,
"fedora-Server-dvd-iso-x86_64-*-64bit": 10
},
"settings": {
"PARTITIONING": "custom_btrfs_preserve_home",
"ROOT_PASSWORD": "weakpassword",
"POSTINSTALL": "btrfs_preserve_home_check_content",
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"HDD_1": "disk_f%CURRREL%_desktop_5_%ARCH%.qcow2"
Add several tests to test QA:Testcase_partitioning_custom_btrfs_preserve_home. This PR adds the `install_btrfs_upload` to install the btrfs based image, the `btrfs_preserve_home_extras` to prepare and test the data on the home partition, as well as the `custom_btrfs_preserve_home` that uses the preinstalled btrfs image and uses its current partitioning to preserve the home partition and the data on it.
2020-11-26 12:37:32 +00:00
}
},
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"install_btrfs_preserve_home_bios": {
Add UEFI versions of cust_btrfs_pres_home and custom_std_part.
2021-03-24 10:57:36 +00:00
"profiles": {
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Server-dvd-iso-x86_64-*-bios": 41
Add UEFI versions of cust_btrfs_pres_home and custom_std_part.
2021-03-24 10:57:36 +00:00
},
"settings": {
"PARTITIONING": "custom_btrfs_preserve_home",
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"HDD_1": "disk_f%CURRREL%_minimal-bios_4_%ARCH%.qcow2",
Add UEFI versions of cust_btrfs_pres_home and custom_std_part.
2021-03-24 10:57:36 +00:00
"POSTINSTALL": "btrfs_preserve_home_check_content",
"ROOT_PASSWORD": "weakpassword"
}
},
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"install_cyrillic_language": {
"profiles": {
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 40,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 40,
"fedora-Server-dvd-iso-x86_64-*-64bit": 40
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"DESKTOP": "gnome",
"ENCRYPT_PASSWORD": "weakpassword",
Increase HDD size from 13 to 15G for language tests because failing in "disk_guided_empty" module at least for PowerPC. Signed-off-by: Guy Menanteau <menantea@linux.vnet.ibm.com>
2020-02-26 10:32:48 +00:00
"HDDSIZEGB": "15",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"LANGUAGE": "russian",
"PACKAGE_SET": "workstation",
"POSTINSTALL": "_console_login",
"QEMU_DISABLE_SNAPSHOTS": "1",
"REPOSITORY_VARIATION": "%LOCATION%",
"ROOT_PASSWORD": "weakpassword",
"SWITCHED_LAYOUT": "1",
"USER_LOGIN": "qwerty"
}
},
"install_default": {
"profiles": {
Run ELN tests on BIOS ELN can't boot with Secure Boot enabled currently: https://github.com/fedora-eln/eln/issues/183 Until that's resolved, let's go back to testing on BIOS (this is easier than testing on non-SB UEFI for...reasons). Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-04-02 22:39:42 +00:00
"fedora-BaseOS-boot-iso-x86_64-*-bios": 50,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-CoreOS-colive-iso-x86_64-*-bios": 21,
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"fedora-Everything-boot-iso-ppc64le-*-ppc64le": 62,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Everything-boot-iso-x86_64-*-bios": 10,
"fedora-Everything-boot-iso-x86_64-*-64bit": 11,
"fedora-KDE-live-iso-x86_64-*-bios": 16,
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"fedora-Server-boot-iso-aarch64-*-aarch64": 10,
"fedora-Server-boot-iso-ppc64le-*-ppc64le": 10,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Server-boot-iso-x86_64-*-bios": 10,
"fedora-Server-boot-iso-x86_64-*-64bit": 11,
"fedora-Server-dvd-iso-x86_64-*-bios": 11,
"fedora-Silverblue-dvd_ostree-iso-x86_64-*-bios": 51,
"fedora-Workstation-live-iso-x86_64-*-bios": 11
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"PACKAGE_SET": "default",
"POSTINSTALL": "_collect_data"
}
},
"install_default_upload": {
"profiles": {
Run ELN tests on BIOS ELN can't boot with Secure Boot enabled currently: https://github.com/fedora-eln/eln/issues/183 Until that's resolved, let's go back to testing on BIOS (this is easier than testing on non-SB UEFI for...reasons). Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-04-02 22:39:42 +00:00
"fedora-BaseOS-dvd-iso-x86_64-*-bios": 50,
Add initial CoreOS product and test templates Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-08-19 21:58:02 +00:00
"fedora-CoreOS-colive-iso-x86_64-*-64bit": 20,
Enable IoT testing with install and base tests IoT is becoming a release-blocking edition for F32, so we should be testing it for sure. We may add specific tests, but for now let's run the install and base tests on it. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-02-13 19:50:32 +00:00
"fedora-IoT-dvd_ostree-iso-aarch64-*-aarch64": 20,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-IoT-dvd_ostree-iso-x86_64-*-64bit": 20,
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"fedora-KDE-live-iso-x86_64-*-64bit": 15,
"fedora-Server-dvd-iso-aarch64-*-aarch64": 10,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 10,
"fedora-Server-dvd-iso-x86_64-*-64bit": 10,
"fedora-Silverblue-dvd_ostree-iso-ppc64le-*-ppc64le": 50,
"fedora-Silverblue-dvd_ostree-iso-x86_64-*-64bit": 50,
"fedora-Workstation-live-iso-ppc64le-*-ppc64le": 10,
Add tests for the Workstation live osbuild image We should test this image to make sure it works as well as the official image. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-02-21 00:06:40 +00:00
"fedora-Workstation-live-iso-x86_64-*-64bit": 10,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Workstation-live_osbuild-iso-x86_64-*-64bit": 60
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"PACKAGE_SET": "default",
"POSTINSTALL": "_collect_data",
"STORE_HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2"
}
},
"install_delete_partial": {
"profiles": {
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 30,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 30,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Server-dvd-iso-x86_64-*-bios": 30,
"fedora-Server-dvd-iso-x86_64-*-64bit": 31
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"HDD_1": "disk_full_%PART_TABLE_TYPE%.img",
"PARTITIONING": "guided_delete_partial",
"ROOT_PASSWORD": "weakpassword"
}
},
"install_delete_pata": {
"profiles": {
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Server-dvd-iso-x86_64-*-bios": 20,
"fedora-Server-dvd-iso-x86_64-*-64bit": 21
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"HDDMODEL": "ide-hd",
"HDD_1": "disk_full_mbr.img",
"PARTITIONING": "guided_delete_all"
}
},
"install_european_language": {
"profiles": {
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 40,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 40,
"fedora-Server-dvd-iso-x86_64-*-64bit": 40
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"DESKTOP": "gnome",
"ENCRYPT_PASSWORD": "weakpassword",
Increase HDD size from 13 to 15G for language tests because failing in "disk_guided_empty" module at least for PowerPC. Signed-off-by: Guy Menanteau <menantea@linux.vnet.ibm.com>
2020-02-26 10:32:48 +00:00
"HDDSIZEGB": "15",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"LANGUAGE": "french",
"NO_UEFI_POST": "1",
"PACKAGE_SET": "workstation",
"POSTINSTALL": "_console_login",
"QEMU_DISABLE_SNAPSHOTS": "1",
"REPOSITORY_VARIATION": "%LOCATION%",
"ROOT_PASSWORD": "weakpassword",
"USER_LOGIN": "qwerty"
}
},
"install_iscsi": {
"profiles": {
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 40,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 40,
"fedora-Server-dvd-iso-x86_64-*-64bit": 40
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
Use qemu host IP 172.16.2.2 not 10.0.2.2 This is to make the infra folks happy, apparently using 10.0.x.x and 10.1.x.x is causing conflicts since our actual infra network uses those ranges too. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-07-17 20:42:48 +00:00
"ANACONDA_STATIC": "172.16.2.111",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"INSTALL_UNLOCK": "support_ready",
"NICTYPE": "tap",
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"PARALLEL_WITH": "support_server_2",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"PARTITIONING": "custom_iscsi",
"ROOT_PASSWORD": "weakpassword",
"WORKER_CLASS": "tap"
}
},
"install_kickstart_firewall_configured": {
"profiles": {
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 20,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 20,
"fedora-Server-dvd-iso-x86_64-*-64bit": 20
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"GRUB": "inst.ks=http://fedorapeople.org/groups/qa/kickstarts/firewall-configured-net.ks",
"KICKSTART": "1",
"POSTINSTALL": "firewall_configured",
"ROOT_PASSWORD": "anaconda",
"USER_LOGIN": "false"
}
},
"install_kickstart_firewall_disabled": {
"profiles": {
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 20,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 20,
"fedora-Server-dvd-iso-x86_64-*-64bit": 20
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"GRUB": "inst.ks=http://fedorapeople.org/groups/qa/kickstarts/firewall-disabled-net.ks",
"KICKSTART": "1",
"POSTINSTALL": "firewall_disabled",
"ROOT_PASSWORD": "anaconda",
"USER_LOGIN": "false"
}
},
"install_kickstart_hdd": {
"profiles": {
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 30,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 30,
"fedora-Server-dvd-iso-x86_64-*-64bit": 30
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"GRUB": "inst.ks=hd:vdb1:/root-user-crypted-net.ks",
Add Samba AD tests This adds a Samba AD server test, and client enrolment tests via sssd, Cockpit and kickstart. Requires the matching createhdds commit to add the kickstart to the disk_ks image. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-07-19 23:41:21 +00:00
"HDD_2": "disk_ks_7.img",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"KICKSTART": "1",
"NUMDISKS": "2",
"ROOT_PASSWORD": "111111",
"USER_LOGIN": "test",
"USER_PASSWORD": "test"
}
},
"install_kickstart_nfs": {
"profiles": {
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 30,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 30,
"fedora-Server-dvd-iso-x86_64-*-64bit": 30
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"GRUB": "inst.ks=nfs:172.16.2.120:/export/root-user-crypted-net.ks",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"INSTALL_UNLOCK": "support_ready",
"KICKSTART": "1",
"NICTYPE": "tap",
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"PARALLEL_WITH": "support_server_2",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"ROOT_PASSWORD": "111111",
"USER_LOGIN": "false",
"WORKER_CLASS": "tap"
}
},
"install_kickstart_user_creation": {
"profiles": {
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 20,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 20,
"fedora-Server-dvd-iso-x86_64-*-64bit": 20
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
Update root-user-crypted-net kickstart usages Use the copy in the group dir (not jskladan's), which I've fixed to not use "install" any more. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2021-01-19 23:03:48 +00:00
"GRUB": "inst.ks=https://fedorapeople.org/groups/qa/kickstarts/root-user-crypted-net.ks",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"KICKSTART": "1",
"ROOT_PASSWORD": "111111",
"USER_LOGIN": "test",
"USER_PASSWORD": "test"
}
},
"install_lvmthin": {
"profiles": {
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 40,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 40,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Server-dvd-iso-x86_64-*-bios": 40,
"fedora-Server-dvd-iso-x86_64-*-64bit": 41
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"PARTITIONING": "custom_lvmthin",
"ROOT_PASSWORD": "weakpassword"
}
},
Add an installation test using LVM partitioning as asset for resize tests. When Fedora went to BTRFS as a default, we lost the LVM based image to run LVM resize tests with. This PR introduces the `install_lvm.pm` installation test that creates an LVM based qcow2 image to be used by follow-up tests.
2020-11-18 12:44:05 +00:00
"install_lvm_ext4": {
"profiles": {
"fedora-Server-dvd-iso-aarch64-*-aarch64": 40,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 40,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Server-dvd-iso-x86_64-*-bios": 40,
"fedora-Server-dvd-iso-x86_64-*-64bit": 41
Add an installation test using LVM partitioning as asset for resize tests. When Fedora went to BTRFS as a default, we lost the LVM based image to run LVM resize tests with. This PR introduces the `install_lvm.pm` installation test that creates an LVM based qcow2 image to be used by follow-up tests.
2020-11-18 12:44:05 +00:00
},
"settings": {
Apply LVM resize disk change to correct test The affected tests start after install_lvm_ext4, so we need to bump HDDSIZEGB there, not in the downstream tests. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-08-03 08:08:29 +00:00
"HDDSIZEGB": "17",
Add a new testcase to test creation of LVM with ext4 using Blivet. This PR adds a test that uses the Blivet interface to create an LVM layout with ext4 filesystem as well as a postinstall test that checks that the LVM layout has been created correctly.
2020-12-08 10:14:40 +00:00
"PARTITIONING": "custom_lvm_ext4",
Add an installation test using LVM partitioning as asset for resize tests. When Fedora went to BTRFS as a default, we lost the LVM based image to run LVM resize tests with. This PR introduces the `install_lvm.pm` installation test that creates an LVM based qcow2 image to be used by follow-up tests.
2020-11-18 12:44:05 +00:00
"ROOT_PASSWORD": "weakpassword",
"STORE_HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2"
}
},
Add an installation test using Standard partitioning with ext4. This PR add the installation test which uses Standard partitioning with an ext4 filesystem to cover one of the new requirements as described in issue #202. Fixed after a review
2020-11-24 13:19:04 +00:00
"install_standard_partition_ext4": {
"profiles": {
"fedora-Server-dvd-iso-aarch64-*-aarch64": 30,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 30,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Server-dvd-iso-x86_64-*-bios": 30,
"fedora-Server-dvd-iso-x86_64-*-64bit": 31
Add an installation test using Standard partitioning with ext4. This PR add the installation test which uses Standard partitioning with an ext4 filesystem to cover one of the new requirements as described in issue #202. Fixed after a review
2020-11-24 13:19:04 +00:00
},
"settings": {
"PARTITIONING": "custom_standard_partition_ext4",
"ROOT_PASSWORD": "weakpassword"
}
},
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"install_mirrorlist_graphical": {
"profiles": {
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 20,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 20,
"fedora-Server-dvd-iso-x86_64-*-64bit": 20
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"MIRRORLIST_GRAPHICAL": "1"
}
},
"install_multi": {
"profiles": {
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 20,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 20,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Server-dvd-iso-x86_64-*-bios": 20,
"fedora-Server-dvd-iso-x86_64-*-64bit": 21
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"HDD_2": "disk_full_mbr.img",
"NUMDISKS": "2",
"PARTITIONING": "guided_multi",
"ROOT_PASSWORD": "weakpassword"
}
},
"install_multi_empty": {
"profiles": {
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 30,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 30,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Server-dvd-iso-x86_64-*-bios": 30,
"fedora-Server-dvd-iso-x86_64-*-64bit": 31
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"NUMDISKS": "2",
"PARTITIONING": "guided_multi_empty_all",
"ROOT_PASSWORD": "weakpassword"
}
},
Add 'with swap' tests, drop swap parts from other tests (#180) In Fedora 33, we generally no longer include a disk-based swap partition by default (instead swap-on-ZRAM is used, see https://fedoraproject.org/wiki/Changes/SwapOnZRAM ). This tweaks our tests to account for that. In tests that aren't to do with swap at all, we stop including a swap partition in order to be closer to the default layout. We replace the old _no_swap blivet and custom tests with _with_swap tests that, as the name implies, *explicitly include* a swap partition, and adjust the postinstall test to check the disk swap partition is there. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-08-11 20:34:37 +00:00
"install_with_swap": {
"profiles": {
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 50,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 50,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Server-dvd-iso-x86_64-*-bios": 50,
"fedora-Server-dvd-iso-x86_64-*-64bit": 51
Add 'with swap' tests, drop swap parts from other tests (#180) In Fedora 33, we generally no longer include a disk-based swap partition by default (instead swap-on-ZRAM is used, see https://fedoraproject.org/wiki/Changes/SwapOnZRAM ). This tweaks our tests to account for that. In tests that aren't to do with swap at all, we stop including a swap partition in order to be closer to the default layout. We replace the old _no_swap blivet and custom tests with _with_swap tests that, as the name implies, *explicitly include* a swap partition, and adjust the postinstall test to check the disk swap partition is there. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-08-11 20:34:37 +00:00
},
"settings": {
"PARTITIONING": "custom_with_swap",
"ROOT_PASSWORD": "weakpassword"
}
},
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"install_no_user": {
"profiles": {
"fedora-KDE-live-iso-x86_64-*-64bit": 21
},
"settings": {
"INSTALL_NO_USER": "1"
}
},
"install_package_set_kde": {
"profiles": {
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 30,
"fedora-Server-dvd-iso-x86_64-*-64bit": 50
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"DESKTOP": "kde",
Bump KDE package set install disk size to 15GiB KDE netinst installs more packages than before, now, so it needs more space. After investigation this is not a bug, it is intended. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2021-02-08 21:28:08 +00:00
"HDDSIZEGB": "15",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"PACKAGE_SET": "kde",
"POSTINSTALL": "_collect_data",
"REPOSITORY_VARIATION": "%LOCATION%"
}
},
"install_package_set_minimal": {
"profiles": {
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 30,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 30,
"fedora-Server-dvd-iso-x86_64-*-64bit": 30
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"PACKAGE_SET": "minimal",
"POSTINSTALL": "_collect_data"
}
},
"install_pxeboot": {
"profiles": {
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 30,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 30,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Server-dvd-iso-x86_64-*-bios": 30,
"fedora-Server-dvd-iso-x86_64-*-64bit": 31
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"+ISO": "",
"DELAYED_START": "1",
Drop use of PXEBOOT, rely on default boot order Per https://progress.opensuse.org/issues/151258 , PXEBOOT=once doesn't work right in current os-autoinst. Now I look at it, PXEBOOT is just pretty ropey in general; on UEFI and aarch64 it doesn't actually do anything at all, we're actually just relying on the default boot order there. Since it doesn't seem like there's a practical way to make PXEBOOT=once work as intended on all platforms, let's just drop use of it and make it clear that we rely on the default boot order: we hope that on first boot we'll get a PXE boot since no local media are bootable, then on second boot we'll get a local disk boot. We set up a new IS_PXE variable to cue the couple of places where the test logic needs to be different. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-11-22 00:23:25 +00:00
"IS_PXE": "1",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"KICKSTART": "1",
"NICTYPE": "tap",
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"PARALLEL_WITH": "support_server_2@%ARCH_BASE_MACHINE%",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"ROOT_PASSWORD": "111111",
"TEST_TARGET": "COMPOSE",
"USER_LOGIN": "false",
"WORKER_CLASS": "tap"
}
},
"install_repository_hd_variation": {
"profiles": {
"fedora-Server-dvd-iso-aarch64-*-aarch64": 30,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 30,
"fedora-Server-dvd-iso-x86_64-*-64bit": 30
},
"settings": {
"HDD_2": "disk_full_mbr.img",
"NUMDISKS": "2",
"PREINSTALL": "preinstall_iso_in_hd",
"REPOSITORY_VARIATION": "hd:vdb1:/fedora_image.iso"
}
},
"install_repository_http_graphical": {
"profiles": {
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 20,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 20,
"fedora-Server-dvd-iso-x86_64-*-64bit": 20
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"REPOSITORY_GRAPHICAL": "%LOCATION%"
}
},
"install_repository_http_variation": {
"profiles": {
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 20,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 20,
"fedora-Server-dvd-iso-x86_64-*-64bit": 20
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"REPOSITORY_VARIATION": "%LOCATION%"
}
},
"install_repository_nfs_graphical": {
"profiles": {
"fedora-Server-dvd-iso-aarch64-*-aarch64": 30,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 30,
"fedora-Server-dvd-iso-x86_64-*-64bit": 30
},
"settings": {
"INSTALL_UNLOCK": "support_ready",
"NICTYPE": "tap",
"PARALLEL_WITH": "support_server",
Use qemu host IP 172.16.2.2 not 10.0.2.2 This is to make the infra folks happy, apparently using 10.0.x.x and 10.1.x.x is causing conflicts since our actual infra network uses those ranges too. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-07-17 20:42:48 +00:00
"REPOSITORY_GRAPHICAL": "nfs:nfsvers=4:172.16.2.110:/repo",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"WORKER_CLASS": "tap"
}
},
"install_repository_nfs_variation": {
"profiles": {
"fedora-Server-dvd-iso-aarch64-*-aarch64": 30,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 30,
"fedora-Server-dvd-iso-x86_64-*-64bit": 30
},
"settings": {
"INSTALL_UNLOCK": "support_ready",
"NICTYPE": "tap",
"PARALLEL_WITH": "support_server",
Use qemu host IP 172.16.2.2 not 10.0.2.2 This is to make the infra folks happy, apparently using 10.0.x.x and 10.1.x.x is causing conflicts since our actual infra network uses those ranges too. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-07-17 20:42:48 +00:00
"REPOSITORY_VARIATION": "nfs:nfsvers=4:172.16.2.110:/repo",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"WORKER_CLASS": "tap"
}
},
"install_repository_nfsiso_variation": {
"profiles": {
"fedora-Server-dvd-iso-aarch64-*-aarch64": 30,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 30,
"fedora-Server-dvd-iso-x86_64-*-64bit": 30
},
"settings": {
"INSTALL_UNLOCK": "support_ready",
"NICTYPE": "tap",
"PARALLEL_WITH": "support_server",
Use qemu host IP 172.16.2.2 not 10.0.2.2 This is to make the infra folks happy, apparently using 10.0.x.x and 10.1.x.x is causing conflicts since our actual infra network uses those ranges too. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-07-17 20:42:48 +00:00
"REPOSITORY_VARIATION": "nfs:nfsvers=4:172.16.2.110:/iso/image.iso",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"WORKER_CLASS": "tap"
}
},
"install_rescue_encrypted": {
"profiles": {
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 31,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 31,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Server-dvd-iso-x86_64-*-bios": 31,
"fedora-Server-dvd-iso-x86_64-*-64bit": 32
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"BOOTFROM": "d",
"ENTRYPOINT": "rescue_mode_encrypted",
"HDD_1": "disk_%MACHINE%_encrypted.qcow2",
"START_AFTER_TEST": "install_simple_encrypted"
}
},
"install_sata": {
"profiles": {
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Server-dvd-iso-x86_64-*-bios": 20,
"fedora-Server-dvd-iso-x86_64-*-64bit": 21
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"ATACONTROLLER": "ich9-ahci",
Use 'ide-hd' instead of deprecated 'ide-drive' in SATA test This was deprecated in qemu 4.2, but only actually taken out in 6.1. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2021-11-08 22:40:47 +00:00
"HDDMODEL": "ide-hd,bus=ahci0.0"
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
}
},
"install_scsi_updates_img": {
"profiles": {
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 20,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 20,
"fedora-Server-dvd-iso-x86_64-*-64bit": 20
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"CDMODEL": "scsi-cd",
"GRUB": "inst.updates=https://fedorapeople.org/groups/qa/updates/updates-openqa.img",
"HDDMODEL": "scsi-hd",
"SCSICONTROLLER": "virtio-scsi-pci",
"TEST_UPDATES": "1"
}
},
"install_serial_console": {
"profiles": {
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 30,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 30,
"fedora-Server-dvd-iso-x86_64-*-64bit": 30
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"ANACONDA_TEXT": "1",
"NO_UEFI_POST": "1",
"SERIAL_CONSOLE": "1",
"VIRTIO_CONSOLE_NUM": "2"
}
},
"install_shrink_ext4": {
"profiles": {
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 40,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 40,
"fedora-Server-dvd-iso-x86_64-*-64bit": 40
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"HDD_1": "disk_shrink_ext4.img",
"PARTITIONING": "guided_shrink",
"ROOT_PASSWORD": "weakpassword"
}
},
"install_shrink_ntfs": {
"profiles": {
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 40,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 40,
"fedora-Server-dvd-iso-x86_64-*-64bit": 40
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"HDD_1": "disk_shrink_ntfs.img",
"PARTITIONING": "guided_shrink",
"ROOT_PASSWORD": "weakpassword"
}
},
"install_simple_encrypted": {
"profiles": {
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 30,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 30,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Server-dvd-iso-x86_64-*-bios": 30,
"fedora-Server-dvd-iso-x86_64-*-64bit": 31
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"ENCRYPT_PASSWORD": "weakpassword",
"STORE_HDD_1": "disk_%MACHINE%_encrypted.qcow2"
}
},
"install_simple_free_space": {
"profiles": {
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 30,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 30,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Server-dvd-iso-x86_64-*-bios": 30,
"fedora-Server-dvd-iso-x86_64-*-64bit": 31
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"HDD_1": "disk_freespace_%PART_TABLE_TYPE%.img",
"PARTITIONING": "guided_free_space",
"ROOT_PASSWORD": "weakpassword"
}
},
"install_software_raid": {
"profiles": {
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 30,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 30,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Server-dvd-iso-x86_64-*-bios": 30,
"fedora-Server-dvd-iso-x86_64-*-64bit": 31
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"NUMDISKS": "2",
"PARTITIONING": "custom_software_raid",
"ROOT_PASSWORD": "weakpassword"
}
},
Add the Turkish installation test. Add turkish console to console_loadkeys_us
2023-06-22 09:53:15 +00:00
"install_turkish_language": {
"profiles": {
"fedora-Server-dvd-iso-aarch64-*-aarch64": 40,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 40,
"fedora-Server-dvd-iso-x86_64-*-64bit": 40
},
"settings": {
"DESKTOP": "gnome",
"ENCRYPT_PASSWORD": "weakpassword",
"HDDSIZEGB": "15",
"LANGUAGE": "turkish",
"NO_UEFI_POST": "1",
"PACKAGE_SET": "workstation",
"POSTINSTALL": "_console_login",
"QEMU_DISABLE_SNAPSHOTS": "1",
"REPOSITORY_VARIATION": "%LOCATION%",
"ROOT_PASSWORD": "weakpassword",
"USER_GECOS": "I;'[] <>i[ \"d,. };[,r]",
"USER_LOGIN": "test",
"USER_PASSWORD": "weakpassword"
}
},
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"install_updates_img_local": {
"profiles": {
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 30,
"fedora-Server-dvd-iso-x86_64-*-64bit": 40
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"GRUB": "inst.updates=hd:LABEL=UPDATES_IMG:/updates.img",
"HDD_2": "disk_updates_img_2.img",
"NUMDISKS": "2",
"TEST_UPDATES": "1"
}
},
"install_updates_nfs": {
"profiles": {
"fedora-Server-dvd-iso-aarch64-*-aarch64": 40,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 40,
"fedora-Server-dvd-iso-x86_64-*-64bit": 40
},
"settings": {
Use qemu host IP 172.16.2.2 not 10.0.2.2 This is to make the infra folks happy, apparently using 10.0.x.x and 10.1.x.x is causing conflicts since our actual infra network uses those ranges too. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-07-17 20:42:48 +00:00
"GRUB": "inst.stage2=nfs:nfsvers=4:172.16.2.110:/repo",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"INSTALL_UNLOCK": "support_ready",
"NICTYPE": "tap",
"PARALLEL_WITH": "support_server",
Bump QEMURAM on install_updates_nfs too It's hitting the 2GiB crash bug as well. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-07-17 23:25:52 +00:00
"QEMURAM": "3072",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"TEST_UPDATES": "1",
"WORKER_CLASS": "tap"
}
},
"install_vnc_client": {
"profiles": {
"fedora-Server-dvd-iso-aarch64-*-aarch64": 40,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 40,
"fedora-Server-dvd-iso-x86_64-*-64bit": 40
},
"settings": {
"BOOTFROM": "c",
"DESKTOP": "gnome",
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"HDD_1": "disk_f%CURRREL%_desktop_5_%ARCH%.qcow2",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"INSTALL": "1",
"NICTYPE": "tap",
"PARALLEL_WITH": "install_vnc_server",
Split VNC client steps in two for aarch64 timing issue So, there's a problem with how we figure out the NetworkManager connection to use in setup_tap_static: it expects the first connection in the list to be the right one, but this is only actually true so long as it's *active*. When we're in the tap case, it's usually not going to actually *work* out of the box on boot (or else we wouldn't need setup_tap_static at all...), so some time after boot, NetworkManager gives up on it and marks it as inactive. And after that, setup_tap_static won't work any more. I never noticed this as a problem before because usually we do setup_tap_static before that point. But it seems in the vnc client tests, on aarch64, desktop boot and login is slow enough that by the time we switch to a VT and try to setup the network, we're very close to that cutoff, and sometimes miss it. This, I hope, avoids the problem by doing the network setup in that test before we deal with the desktop login, then doing the desktop login, then doing the actual VNC bits. The alternative here would be to figure out a better way to do setup_tap_static, but I can't. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 18:27:45 +00:00
"PREINSTALL": "_vnc_client_connect_pre _graphical_wait_login _vnc_client_connect",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"VNC_CLIENT": "1",
"WORKER_CLASS": "tap"
}
},
"install_vnc_server": {
"profiles": {
"fedora-Server-dvd-iso-aarch64-*-aarch64": 40,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 40,
"fedora-Server-dvd-iso-x86_64-*-64bit": 40
},
"settings": {
Use 'test.openqa.fedoraproject.org' not 'domain.local' Using .local is apparently Bad Form because it's reserved for mDNS. However there doesn't appear to be any particularly Good Form for what to call a test domain you never want to exist outside of a closed system, apparently. Sigh. Let's try this. Includes a bump to disk_ks version because the kickstarts on that image also need to have this change applied. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-12-15 20:43:53 +00:00
"GRUB": "inst.vnc net.ifnames=0 biosdevname=0 ip=172.16.2.114::172.16.2.2:255.255.255.0:vnc001.test.openqa.fedoraproject.org:eth0:off",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"NICTYPE": "tap",
"VNC_SERVER": "1",
"WORKER_CLASS": "tap"
}
},
"install_vncconnect_client": {
"profiles": {
"fedora-Server-dvd-iso-aarch64-*-aarch64": 40,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 40,
"fedora-Server-dvd-iso-x86_64-*-64bit": 40
},
"settings": {
"BOOTFROM": "c",
"DESKTOP": "gnome",
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"HDD_1": "disk_f%CURRREL%_desktop_5_%ARCH%.qcow2",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"INSTALL": "1",
"NICTYPE": "tap",
Split VNC client steps in two for aarch64 timing issue So, there's a problem with how we figure out the NetworkManager connection to use in setup_tap_static: it expects the first connection in the list to be the right one, but this is only actually true so long as it's *active*. When we're in the tap case, it's usually not going to actually *work* out of the box on boot (or else we wouldn't need setup_tap_static at all...), so some time after boot, NetworkManager gives up on it and marks it as inactive. And after that, setup_tap_static won't work any more. I never noticed this as a problem before because usually we do setup_tap_static before that point. But it seems in the vnc client tests, on aarch64, desktop boot and login is slow enough that by the time we switch to a VT and try to setup the network, we're very close to that cutoff, and sometimes miss it. This, I hope, avoids the problem by doing the network setup in that test before we deal with the desktop login, then doing the desktop login, then doing the actual VNC bits. The alternative here would be to figure out a better way to do setup_tap_static, but I can't. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 18:27:45 +00:00
"PREINSTALL": "_vncconnect_client_setup_pre _graphical_wait_login _vncconnect_client_setup",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"VNC_CLIENT": "1",
"WORKER_CLASS": "tap"
}
},
"install_vncconnect_server": {
"profiles": {
"fedora-Server-dvd-iso-aarch64-*-aarch64": 40,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 40,
"fedora-Server-dvd-iso-x86_64-*-64bit": 40
},
"settings": {
Use 'test.openqa.fedoraproject.org' not 'domain.local' Using .local is apparently Bad Form because it's reserved for mDNS. However there doesn't appear to be any particularly Good Form for what to call a test domain you never want to exist outside of a closed system, apparently. Sigh. Let's try this. Includes a bump to disk_ks version because the kickstarts on that image also need to have this change applied. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-12-15 20:43:53 +00:00
"GRUB": "inst.vnc inst.vncconnect=172.16.2.117:5500 net.ifnames=0 biosdevname=0 ip=172.16.2.116::172.16.2.2:255.255.255.0:vnc003.test.openqa.fedoraproject.org:eth0:off",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"INSTALL_UNLOCK": "vncconnect_client_ready",
"NICTYPE": "tap",
"PARALLEL_WITH": "install_vncconnect_client",
"VNC_SERVER": "1",
"WORKER_CLASS": "tap"
}
},
"install_xfs": {
"profiles": {
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 40,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 40,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Server-dvd-iso-x86_64-*-bios": 40,
"fedora-Server-dvd-iso-x86_64-*-64bit": 41
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"PARTITIONING": "custom_xfs",
"ROOT_PASSWORD": "weakpassword"
}
},
Add QA:Testcase_Clevis test (TPM-based automatic decryption) This adds a test that automates https://fedoraproject.org/wiki/QA:Testcase_Clevis. It requires os-autoinst-4.6-18.20200623git5038d8c or newer, and a worker host in the 'tpm' class which is set up to have an instance of swtpm running at /tmp/mytpmX , where X is the worker instance number, for each worker. The Fedora infrastructure ansible plays have been updated to handle this via an instantiated systemd service, which other instances can also adopt. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-06-19 21:14:57 +00:00
"iot_clevis": {
"profiles": {
"fedora-IoT-dvd_ostree-iso-aarch64-*-aarch64": 20,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-IoT-dvd_ostree-iso-x86_64-*-64bit": 20
Add QA:Testcase_Clevis test (TPM-based automatic decryption) This adds a test that automates https://fedoraproject.org/wiki/QA:Testcase_Clevis. It requires os-autoinst-4.6-18.20200623git5038d8c or newer, and a worker host in the 'tpm' class which is set up to have an instance of swtpm running at /tmp/mytpmX , where X is the worker instance number, for each worker. The Fedora infrastructure ansible plays have been updated to handle this via an instantiated systemd service, which other instances can also adopt. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-06-19 21:14:57 +00:00
},
"settings": {
"ENCRYPT_PASSWORD": "weakpassword",
"POSTINSTALL": "iot_clevis",
"QEMUTPM": "instance",
"ROOT_PASSWORD": "weakpassword",
"WORKER_CLASS": "tpm"
}
},
Create test for IoT Greenboot. Finish test and add necessary needles. Create IOT needle directory and move needles in it. Delete needle as required by the review. Add to templates.
2020-05-27 12:49:22 +00:00
"iot_greenboot": {
"profiles": {
"fedora-IoT-dvd_ostree-iso-aarch64-*-aarch64": 20,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-IoT-dvd_ostree-iso-x86_64-*-64bit": 20
Create test for IoT Greenboot. Finish test and add necessary needles. Create IOT needle directory and move needles in it. Delete needle as required by the review. Add to templates.
2020-05-27 12:49:22 +00:00
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"POSTINSTALL": "iot_greenboot",
"ROOT_PASSWORD": "weakpassword",
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%"
Create test for IoT Greenboot. Finish test and add necessary needles. Create IOT needle directory and move needles in it. Delete needle as required by the review. Add to templates.
2020-05-27 12:49:22 +00:00
}
},
Automate QA:Testcase_Zezere_Ignition This is a bit complex to automate, because we cannot really use the production Zezere server (provision.fedoraproject.org) as the test case shows, as we'd have to solve authentication and we also don't really want to constantly keep registering new hosts to it that are going to disappear and never be seen again. So, instead we'll do it by setting up our *own* Zezere, and provisioning our IoT system in that. We run two tests. The 'ignition' test is the actual IoT 'device'; all it really does is boot up, sit around, and wait to be provisioned. The 'server' test first sets up a Zezere server, then logs into it, adds an ssh key, claims the IoT device, provisions it, and connects to it to create a special file which tells the 'ignition' test everything worked and it can close out. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-07-15 21:56:32 +00:00
"iot_zezere_ignition": {
"profiles": {
"fedora-IoT-dvd_ostree-iso-aarch64-*-aarch64": 20,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-IoT-dvd_ostree-iso-x86_64-*-64bit": 40
Automate QA:Testcase_Zezere_Ignition This is a bit complex to automate, because we cannot really use the production Zezere server (provision.fedoraproject.org) as the test case shows, as we'd have to solve authentication and we also don't really want to constantly keep registering new hosts to it that are going to disappear and never be seen again. So, instead we'll do it by setting up our *own* Zezere, and provisioning our IoT system in that. We run two tests. The 'ignition' test is the actual IoT 'device'; all it really does is boot up, sit around, and wait to be provisioned. The 'server' test first sets up a Zezere server, then logs into it, adds an ssh key, claims the IoT device, provisions it, and connects to it to create a special file which tells the 'ignition' test everything worked and it can close out. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-07-15 21:56:32 +00:00
},
"settings": {
"BOOTFROM": "c",
Use nmcli for static network stuff, not ifcfg files This should work even if the ifcfg plugin is not present (hi, CoreOS) or 'predictable' (har) network names are on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-08-21 22:56:44 +00:00
"GRUB_POSTINSTALL": "zezere.url=http://172.16.2.118",
Automate QA:Testcase_Zezere_Ignition This is a bit complex to automate, because we cannot really use the production Zezere server (provision.fedoraproject.org) as the test case shows, as we'd have to solve authentication and we also don't really want to constantly keep registering new hosts to it that are going to disappear and never be seen again. So, instead we'll do it by setting up our *own* Zezere, and provisioning our IoT system in that. We run two tests. The 'ignition' test is the actual IoT 'device'; all it really does is boot up, sit around, and wait to be provisioned. The 'server' test first sets up a Zezere server, then logs into it, adds an ssh key, claims the IoT device, provisions it, and connects to it to create a special file which tells the 'ignition' test everything worked and it can close out. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-07-15 21:56:32 +00:00
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"NICTYPE": "tap",
"PARALLEL_WITH": "iot_zezere_server",
"POSTINSTALL": "iot_zezere_ignition",
Use 'test.openqa.fedoraproject.org' not 'domain.local' Using .local is apparently Bad Form because it's reserved for mDNS. However there doesn't appear to be any particularly Good Form for what to call a test domain you never want to exist outside of a closed system, apparently. Sigh. Let's try this. Includes a bump to disk_ks version because the kickstarts on that image also need to have this change applied. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-12-15 20:43:53 +00:00
"POST_STATIC": "172.16.2.119 zezere001.test.openqa.fedoraproject.org",
Automate QA:Testcase_Zezere_Ignition This is a bit complex to automate, because we cannot really use the production Zezere server (provision.fedoraproject.org) as the test case shows, as we'd have to solve authentication and we also don't really want to constantly keep registering new hosts to it that are going to disappear and never be seen again. So, instead we'll do it by setting up our *own* Zezere, and provisioning our IoT system in that. We run two tests. The 'ignition' test is the actual IoT 'device'; all it really does is boot up, sit around, and wait to be provisioned. The 'server' test first sets up a Zezere server, then logs into it, adds an ssh key, claims the IoT device, provisions it, and connects to it to create a special file which tells the 'ignition' test everything worked and it can close out. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-07-15 21:56:32 +00:00
"ROOT_PASSWORD": "weakpassword",
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%",
Automate QA:Testcase_Zezere_Ignition This is a bit complex to automate, because we cannot really use the production Zezere server (provision.fedoraproject.org) as the test case shows, as we'd have to solve authentication and we also don't really want to constantly keep registering new hosts to it that are going to disappear and never be seen again. So, instead we'll do it by setting up our *own* Zezere, and provisioning our IoT system in that. We run two tests. The 'ignition' test is the actual IoT 'device'; all it really does is boot up, sit around, and wait to be provisioned. The 'server' test first sets up a Zezere server, then logs into it, adds an ssh key, claims the IoT device, provisions it, and connects to it to create a special file which tells the 'ignition' test everything worked and it can close out. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-07-15 21:56:32 +00:00
"USER_LOGIN": "false",
"WORKER_CLASS": "tap"
}
},
"iot_zezere_server": {
"profiles": {
"fedora-IoT-dvd_ostree-iso-aarch64-*-aarch64": 20,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-IoT-dvd_ostree-iso-x86_64-*-64bit": 40
Automate QA:Testcase_Zezere_Ignition This is a bit complex to automate, because we cannot really use the production Zezere server (provision.fedoraproject.org) as the test case shows, as we'd have to solve authentication and we also don't really want to constantly keep registering new hosts to it that are going to disappear and never be seen again. So, instead we'll do it by setting up our *own* Zezere, and provisioning our IoT system in that. We run two tests. The 'ignition' test is the actual IoT 'device'; all it really does is boot up, sit around, and wait to be provisioned. The 'server' test first sets up a Zezere server, then logs into it, adds an ssh key, claims the IoT device, provisions it, and connects to it to create a special file which tells the 'ignition' test everything worked and it can close out. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-07-15 21:56:32 +00:00
},
"settings": {
"BOOTFROM": "c",
Set empty CANNED for iot_zezere_server This test runs on the minimal disk image, which is an RPM-based system, it is not ostree. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-03-02 22:03:06 +00:00
"CANNED": "",
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"HDD_1": "disk_f%CURRREL%_minimal_4_%ARCH%.qcow2",
Automate QA:Testcase_Zezere_Ignition This is a bit complex to automate, because we cannot really use the production Zezere server (provision.fedoraproject.org) as the test case shows, as we'd have to solve authentication and we also don't really want to constantly keep registering new hosts to it that are going to disappear and never be seen again. So, instead we'll do it by setting up our *own* Zezere, and provisioning our IoT system in that. We run two tests. The 'ignition' test is the actual IoT 'device'; all it really does is boot up, sit around, and wait to be provisioned. The 'server' test first sets up a Zezere server, then logs into it, adds an ssh key, claims the IoT device, provisions it, and connects to it to create a special file which tells the 'ignition' test everything worked and it can close out. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-07-15 21:56:32 +00:00
"NICTYPE": "tap",
"PARALLEL_CANCEL_WHOLE_CLUSTER": "0",
"POSTINSTALL": "_iot_zezere_server _setup_browser _iot_zezere_remote",
Use 'test.openqa.fedoraproject.org' not 'domain.local' Using .local is apparently Bad Form because it's reserved for mDNS. However there doesn't appear to be any particularly Good Form for what to call a test domain you never want to exist outside of a closed system, apparently. Sigh. Let's try this. Includes a bump to disk_ks version because the kickstarts on that image also need to have this change applied. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-12-15 20:43:53 +00:00
"POST_STATIC": "172.16.2.118 zezere002.test.openqa.fedoraproject.org",
Automate QA:Testcase_Zezere_Ignition This is a bit complex to automate, because we cannot really use the production Zezere server (provision.fedoraproject.org) as the test case shows, as we'd have to solve authentication and we also don't really want to constantly keep registering new hosts to it that are going to disappear and never be seen again. So, instead we'll do it by setting up our *own* Zezere, and provisioning our IoT system in that. We run two tests. The 'ignition' test is the actual IoT 'device'; all it really does is boot up, sit around, and wait to be provisioned. The 'server' test first sets up a Zezere server, then logs into it, adds an ssh key, claims the IoT device, provisions it, and connects to it to create a special file which tells the 'ignition' test everything worked and it can close out. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-07-15 21:56:32 +00:00
"ROOT_PASSWORD": "weakpassword",
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%",
Automate QA:Testcase_Zezere_Ignition This is a bit complex to automate, because we cannot really use the production Zezere server (provision.fedoraproject.org) as the test case shows, as we'd have to solve authentication and we also don't really want to constantly keep registering new hosts to it that are going to disappear and never be seen again. So, instead we'll do it by setting up our *own* Zezere, and provisioning our IoT system in that. We run two tests. The 'ignition' test is the actual IoT 'device'; all it really does is boot up, sit around, and wait to be provisioned. The 'server' test first sets up a Zezere server, then logs into it, adds an ssh key, claims the IoT device, provisions it, and connects to it to create a special file which tells the 'ignition' test everything worked and it can close out. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-07-15 21:56:32 +00:00
"TEST_TARGET": "NONE",
"USER_LOGIN": "false",
"WORKER_CLASS": "tap"
}
},
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"mediakit_fileconflicts": {
"profiles": {
"fedora-Server-dvd-iso-aarch64-*-aarch64": 10,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 10,
"fedora-Server-dvd-iso-x86_64-*-64bit": 10
},
"settings": {
"BOOTFROM": "c",
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"HDD_1": "disk_f%CURRREL%_support_6_%ARCH%.qcow2",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"POSTINSTALL": "mediakit_fileconflicts",
"ROOT_PASSWORD": "weakpassword",
"USER_LOGIN": "false"
}
},
"mediakit_repoclosure": {
"profiles": {
"fedora-Server-dvd-iso-aarch64-*-aarch64": 10,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 10,
"fedora-Server-dvd-iso-x86_64-*-64bit": 10
},
"settings": {
"BOOTFROM": "c",
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"HDD_1": "disk_f%CURRREL%_support_6_%ARCH%.qcow2",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"POSTINSTALL": "mediakit_repoclosure",
"ROOT_PASSWORD": "weakpassword",
"USER_LOGIN": "false"
}
},
"memory_check": {
Re-enable memory_check test (on Everything, with WS packages) We were only running this test on the Workstation boot ISO... then that was removed, and so we actually never ran this test at all any more. We should run it on at least one image as check- compose uses the output to check whether installer memory usage has increased. I initially ran it on Workstation as that installs the most packages; so let's run it on Everything but use the Workstation package set. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-25 15:11:17 +00:00
"profiles": {
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Everything-boot-iso-x86_64-*-bios": 30,
"fedora-Everything-boot-iso-x86_64-*-64bit": 31
Re-enable memory_check test (on Everything, with WS packages) We were only running this test on the Workstation boot ISO... then that was removed, and so we actually never ran this test at all any more. We should run it on at least one image as check- compose uses the output to check whether installer memory usage has increased. I initially ran it on Workstation as that installs the most packages; so let's run it on Everything but use the Workstation package set. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-25 15:11:17 +00:00
},
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"settings": {
Bump memory_check disk size again Needs more due to new EFI system partition size. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-06-10 16:10:16 +00:00
"HDDSIZEGB": "14",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"MEMCHECK": "1",
Re-enable memory_check test (on Everything, with WS packages) We were only running this test on the Workstation boot ISO... then that was removed, and so we actually never ran this test at all any more. We should run it on at least one image as check- compose uses the output to check whether installer memory usage has increased. I initially ran it on Workstation as that installs the most packages; so let's run it on Everything but use the Workstation package set. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-25 15:11:17 +00:00
"PACKAGE_SET": "workstation",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"REPOSITORY_VARIATION": "%LOCATION%",
"TEST_TARGET": "NONE"
}
},
Add QA:Testcase_Podman test and run it on IoT (#166) This adds a pair of tests, one which does almost all the work from the test case, the other just a client test to check that we can connect to an HTTP server running in a container on the host. We also have to bump the _console_wait_login timeout on this path a bit as we're booting a disk image that was installed with DHCP working, but we change the network setup so DHCP does not work any more, and the system spends quite some time trying to bring the network up on boot before eventually giving up and proceeding. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-05-27 22:48:02 +00:00
"podman": {
"profiles": {
Add initial CoreOS product and test templates Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-08-19 21:58:02 +00:00
"fedora-CoreOS-colive-iso-x86_64-*-64bit": 20,
Add QA:Testcase_Podman test and run it on IoT (#166) This adds a pair of tests, one which does almost all the work from the test case, the other just a client test to check that we can connect to an HTTP server running in a container on the host. We also have to bump the _console_wait_login timeout on this path a bit as we're booting a disk image that was installed with DHCP working, but we change the network setup so DHCP does not work any more, and the system spends quite some time trying to bring the network up on boot before eventually giving up and proceeding. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-05-27 22:48:02 +00:00
"fedora-IoT-dvd_ostree-iso-aarch64-*-aarch64": 20,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-IoT-dvd_ostree-iso-x86_64-*-64bit": 40
Add QA:Testcase_Podman test and run it on IoT (#166) This adds a pair of tests, one which does almost all the work from the test case, the other just a client test to check that we can connect to an HTTP server running in a container on the host. We also have to bump the _console_wait_login timeout on this path a bit as we're booting a disk image that was installed with DHCP working, but we change the network setup so DHCP does not work any more, and the system spends quite some time trying to bring the network up on boot before eventually giving up and proceeding. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-05-27 22:48:02 +00:00
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"NICTYPE": "tap",
"POSTINSTALL": "podman",
Use 'test.openqa.fedoraproject.org' not 'domain.local' Using .local is apparently Bad Form because it's reserved for mDNS. However there doesn't appear to be any particularly Good Form for what to call a test domain you never want to exist outside of a closed system, apparently. Sigh. Let's try this. Includes a bump to disk_ks version because the kickstarts on that image also need to have this change applied. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-12-15 20:43:53 +00:00
"POST_STATIC": "172.16.2.114 podman001.test.openqa.fedoraproject.org",
Add QA:Testcase_Podman test and run it on IoT (#166) This adds a pair of tests, one which does almost all the work from the test case, the other just a client test to check that we can connect to an HTTP server running in a container on the host. We also have to bump the _console_wait_login timeout on this path a bit as we're booting a disk image that was installed with DHCP working, but we change the network setup so DHCP does not work any more, and the system spends quite some time trying to bring the network up on boot before eventually giving up and proceeding. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-05-27 22:48:02 +00:00
"ROOT_PASSWORD": "weakpassword",
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%",
Add QA:Testcase_Podman test and run it on IoT (#166) This adds a pair of tests, one which does almost all the work from the test case, the other just a client test to check that we can connect to an HTTP server running in a container on the host. We also have to bump the _console_wait_login timeout on this path a bit as we're booting a disk image that was installed with DHCP working, but we change the network setup so DHCP does not work any more, and the system spends quite some time trying to bring the network up on boot before eventually giving up and proceeding. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-05-27 22:48:02 +00:00
"USER_LOGIN": "false",
Move some tap job groups to new 'tap2' worker class This is intended to allow us to split the workload across multiple tap workers, as right now, sometimes we wind up in a situation where all non-tap jobs are done and the non-tap workers are sitting idle, but the poor tap worker has a backlog. This way the tap jobs for updates can be split across two worker hosts, which should help out. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-11-26 01:33:31 +00:00
"WORKER_CLASS": "tap2"
Add QA:Testcase_Podman test and run it on IoT (#166) This adds a pair of tests, one which does almost all the work from the test case, the other just a client test to check that we can connect to an HTTP server running in a container on the host. We also have to bump the _console_wait_login timeout on this path a bit as we're booting a disk image that was installed with DHCP working, but we change the network setup so DHCP does not work any more, and the system spends quite some time trying to bring the network up on boot before eventually giving up and proceeding. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-05-27 22:48:02 +00:00
}
},
"podman_client": {
"profiles": {
Add initial CoreOS product and test templates Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-08-19 21:58:02 +00:00
"fedora-CoreOS-colive-iso-x86_64-*-64bit": 20,
Add QA:Testcase_Podman test and run it on IoT (#166) This adds a pair of tests, one which does almost all the work from the test case, the other just a client test to check that we can connect to an HTTP server running in a container on the host. We also have to bump the _console_wait_login timeout on this path a bit as we're booting a disk image that was installed with DHCP working, but we change the network setup so DHCP does not work any more, and the system spends quite some time trying to bring the network up on boot before eventually giving up and proceeding. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-05-27 22:48:02 +00:00
"fedora-IoT-dvd_ostree-iso-aarch64-*-aarch64": 20,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-IoT-dvd_ostree-iso-x86_64-*-64bit": 40
Add QA:Testcase_Podman test and run it on IoT (#166) This adds a pair of tests, one which does almost all the work from the test case, the other just a client test to check that we can connect to an HTTP server running in a container on the host. We also have to bump the _console_wait_login timeout on this path a bit as we're booting a disk image that was installed with DHCP working, but we change the network setup so DHCP does not work any more, and the system spends quite some time trying to bring the network up on boot before eventually giving up and proceeding. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-05-27 22:48:02 +00:00
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"NICTYPE": "tap",
"PARALLEL_WITH": "podman",
"POSTINSTALL": "_podman_client",
Use 'test.openqa.fedoraproject.org' not 'domain.local' Using .local is apparently Bad Form because it's reserved for mDNS. However there doesn't appear to be any particularly Good Form for what to call a test domain you never want to exist outside of a closed system, apparently. Sigh. Let's try this. Includes a bump to disk_ks version because the kickstarts on that image also need to have this change applied. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-12-15 20:43:53 +00:00
"POST_STATIC": "172.16.2.115 podclient001.test.openqa.fedoraproject.org",
Add QA:Testcase_Podman test and run it on IoT (#166) This adds a pair of tests, one which does almost all the work from the test case, the other just a client test to check that we can connect to an HTTP server running in a container on the host. We also have to bump the _console_wait_login timeout on this path a bit as we're booting a disk image that was installed with DHCP working, but we change the network setup so DHCP does not work any more, and the system spends quite some time trying to bring the network up on boot before eventually giving up and proceeding. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-05-27 22:48:02 +00:00
"ROOT_PASSWORD": "weakpassword",
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%",
Add QA:Testcase_Podman test and run it on IoT (#166) This adds a pair of tests, one which does almost all the work from the test case, the other just a client test to check that we can connect to an HTTP server running in a container on the host. We also have to bump the _console_wait_login timeout on this path a bit as we're booting a disk image that was installed with DHCP working, but we change the network setup so DHCP does not work any more, and the system spends quite some time trying to bring the network up on boot before eventually giving up and proceeding. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-05-27 22:48:02 +00:00
"USER_LOGIN": "false",
Move some tap job groups to new 'tap2' worker class This is intended to allow us to split the workload across multiple tap workers, as right now, sometimes we wind up in a situation where all non-tap jobs are done and the non-tap workers are sitting idle, but the poor tap worker has a backlog. This way the tap jobs for updates can be split across two worker hosts, which should help out. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-11-26 01:33:31 +00:00
"WORKER_CLASS": "tap2"
Add QA:Testcase_Podman test and run it on IoT (#166) This adds a pair of tests, one which does almost all the work from the test case, the other just a client test to check that we can connect to an HTTP server running in a container on the host. We also have to bump the _console_wait_login timeout on this path a bit as we're booting a disk image that was installed with DHCP working, but we change the network setup so DHCP does not work any more, and the system spends quite some time trying to bring the network up on boot before eventually giving up and proceeding. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-05-27 22:48:02 +00:00
}
},
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"realmd_join_cockpit": {
"profiles": {
"fedora-Server-dvd-iso-aarch64-*-aarch64": 30,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 30,
"fedora-Server-dvd-iso-x86_64-*-64bit": 30
},
"settings": {
"+HDD_1": "disk_%MACHINE%_cockpit.qcow2",
"+START_AFTER_TEST": "server_cockpit_default",
"BOOTFROM": "c",
"NICTYPE": "tap",
"PARALLEL_WITH": "server_role_deploy_domain_controller",
Add Samba AD tests This adds a Samba AD server test, and client enrolment tests via sssd, Cockpit and kickstart. Requires the matching createhdds commit to add the kickstart to the disk_ks image. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-07-19 23:41:21 +00:00
"POSTINSTALL": "realmd_join_cockpit freeipa_webui freeipa_password_change domain_client",
Use 'test.openqa.fedoraproject.org' not 'domain.local' Using .local is apparently Bad Form because it's reserved for mDNS. However there doesn't appear to be any particularly Good Form for what to call a test domain you never want to exist outside of a closed system, apparently. Sigh. Let's try this. Includes a bump to disk_ks version because the kickstarts on that image also need to have this change applied. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-12-15 20:43:53 +00:00
"POST_STATIC": "172.16.2.102 client002.test.openqa.fedoraproject.org",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"ROOT_PASSWORD": "weakpassword",
"USER_LOGIN": "false",
"WORKER_CLASS": "tap"
}
},
Add Samba AD tests This adds a Samba AD server test, and client enrolment tests via sssd, Cockpit and kickstart. Requires the matching createhdds commit to add the kickstart to the disk_ks image. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-07-19 23:41:21 +00:00
"realmd_join_cockpit_ad": {
"profiles": {
"fedora-Server-dvd-iso-aarch64-*-aarch64": 30,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 30,
"fedora-Server-dvd-iso-x86_64-*-64bit": 30
},
"settings": {
"+HDD_1": "disk_%MACHINE%_cockpit.qcow2",
"+START_AFTER_TEST": "server_cockpit_default",
"BOOTFROM": "c",
"NICTYPE": "tap",
"PARALLEL_WITH": "server_samba_domain_controller",
"POSTINSTALL": "realmd_join_cockpit domain_client",
"POST_STATIC": "172.16.2.132 adclient002.samdom.openqa.fedoraproject.org",
"REALMD_ADMIN_USER": "administrator",
"REALMD_ADMIN_PASSWORD": "129ho3eau47#qm9to9s^",
"REALMD_DNS_SERVER_HOST": "ad001.samdom.openqa.fedoraproject.org",
"REALMD_DNS_SERVER_IP": "172.16.2.130",
"REALMD_DOMAIN": "samdom.openqa.fedoraproject.org",
"ROOT_PASSWORD": "weakpassword",
"USER_LOGIN": "false",
"WORKER_CLASS": "tap"
}
},
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"realmd_join_sssd": {
"profiles": {
"fedora-Server-dvd-iso-aarch64-*-aarch64": 20,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 20,
"fedora-Server-dvd-iso-x86_64-*-64bit": 20
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"NICTYPE": "tap",
"PARALLEL_WITH": "server_role_deploy_domain_controller",
Add Samba AD tests This adds a Samba AD server test, and client enrolment tests via sssd, Cockpit and kickstart. Requires the matching createhdds commit to add the kickstart to the disk_ks image. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-07-19 23:41:21 +00:00
"POSTINSTALL": "realmd_join_sssd domain_client",
Use 'test.openqa.fedoraproject.org' not 'domain.local' Using .local is apparently Bad Form because it's reserved for mDNS. However there doesn't appear to be any particularly Good Form for what to call a test domain you never want to exist outside of a closed system, apparently. Sigh. Let's try this. Includes a bump to disk_ks version because the kickstarts on that image also need to have this change applied. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-12-15 20:43:53 +00:00
"POST_STATIC": "172.16.2.103 client003.test.openqa.fedoraproject.org",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"ROOT_PASSWORD": "weakpassword",
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"USER_LOGIN": "false",
"WORKER_CLASS": "tap"
}
},
Add Samba AD tests This adds a Samba AD server test, and client enrolment tests via sssd, Cockpit and kickstart. Requires the matching createhdds commit to add the kickstart to the disk_ks image. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-07-19 23:41:21 +00:00
"realmd_join_sssd_ad": {
"profiles": {
"fedora-Server-dvd-iso-aarch64-*-aarch64": 20,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 20,
"fedora-Server-dvd-iso-x86_64-*-64bit": 20
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"NICTYPE": "tap",
"PARALLEL_WITH": "server_samba_domain_controller",
"POSTINSTALL": "realmd_join_sssd domain_client",
"POST_STATIC": "172.16.2.131 adclient001.samdom.openqa.fedoraproject.org",
"REALMD_ADMIN_USER": "administrator",
"REALMD_ADMIN_PASSWORD": "129ho3eau47#qm9to9s^",
"REALMD_DNS_SERVER_HOST": "ad001.samdom.openqa.fedoraproject.org",
"REALMD_DNS_SERVER_IP": "172.16.2.130",
"REALMD_DOMAIN": "samdom.openqa.fedoraproject.org",
"ROOT_PASSWORD": "weakpassword",
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%",
"USER_LOGIN": "false",
"WORKER_CLASS": "tap"
}
},
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"release_identification": {
"profiles": {
Enable more base tests on aarch64 images, fix up priorities a bit Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:57:24 +00:00
"fedora-CoreOS-colive-iso-x86_64-*-64bit": 50,
"fedora-IoT-dvd_ostree-iso-aarch64-*-aarch64": 40,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-IoT-dvd_ostree-iso-x86_64-*-64bit": 40,
Enable more base tests on aarch64 images, fix up priorities a bit Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:57:24 +00:00
"fedora-KDE-live-iso-x86_64-*-64bit": 42,
"fedora-Minimal-raw_xz-raw.xz-aarch64-*-aarch64": 42,
"fedora-Server-dvd-iso-aarch64-*-aarch64": 40,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 40,
"fedora-Server-dvd-iso-x86_64-*-64bit": 40,
"fedora-Server-raw_xz-raw.xz-aarch64-*-aarch64": 42,
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"fedora-Silverblue-dvd_ostree-iso-ppc64le-*-ppc64le": 50,
"fedora-Silverblue-dvd_ostree-iso-x86_64-*-64bit": 50,
Enable more base tests on aarch64 images, fix up priorities a bit Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:57:24 +00:00
"fedora-Workstation-live-iso-ppc64le-*-ppc64le": 40,
"fedora-Workstation-live-iso-x86_64-*-64bit": 40,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Workstation-live_osbuild-iso-x86_64-*-64bit": 60,
Rename tests and flavours as per review.
2021-12-07 10:30:21 +00:00
"fedora-Workstation-upgrade-x86_64-*-64bit": 40,
"fedora-Workstation-upgrade-aarch64-*-aarch64": 40,
Enable more base tests on aarch64 images, fix up priorities a bit Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:57:24 +00:00
"fedora-Workstation-raw_xz-raw.xz-aarch64-*-aarch64": 42
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"BOOTFROM": "c",
"ENTRYPOINT": "text_login_gui fedora_release os_release",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"USER_LOGIN": "false"
}
},
Make rpm-ostree tests generic, run on Silverblue and CoreOS This makes the two rpm-ostree tests written for IoT - overlaying and rebasing - work across all rpm-ostree-based flavors we currently test (IoT, CoreOS and Silverblue) and runs them on all those flavors. This requires some other changes. For the Workstation ostree installer update tests, we have install_default_update_ostree upload a disk image and run these tests on that image. That means install_default_update_ostree cannot use a scratch disk (as if we boot it with two disks but only upload one, the subsequent tests fail to boot, looking for the missing second disk), but its specified disk size should be large enough for all updates. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-12-06 22:41:56 +00:00
"rpmostree_overlay": {
"profiles": {
"fedora-CoreOS-colive-iso-x86_64-*-64bit": 20,
"fedora-IoT-dvd_ostree-iso-aarch64-*-aarch64": 20,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-IoT-dvd_ostree-iso-x86_64-*-64bit": 20,
Make rpm-ostree tests generic, run on Silverblue and CoreOS This makes the two rpm-ostree tests written for IoT - overlaying and rebasing - work across all rpm-ostree-based flavors we currently test (IoT, CoreOS and Silverblue) and runs them on all those flavors. This requires some other changes. For the Workstation ostree installer update tests, we have install_default_update_ostree upload a disk image and run these tests on that image. That means install_default_update_ostree cannot use a scratch disk (as if we boot it with two disks but only upload one, the subsequent tests fail to boot, looking for the missing second disk), but its specified disk size should be large enough for all updates. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-12-06 22:41:56 +00:00
"fedora-Silverblue-dvd_ostree-iso-ppc64le-*-ppc64le": 50,
"fedora-Silverblue-dvd_ostree-iso-x86_64-*-64bit": 50
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"POSTINSTALL": "rpmostree_overlay",
"ROOT_PASSWORD": "weakpassword",
"+START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%"
}
},
"rpmostree_rebase": {
"profiles": {
"fedora-CoreOS-colive-iso-x86_64-*-64bit": 20,
"fedora-IoT-dvd_ostree-iso-aarch64-*-aarch64": 20,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-IoT-dvd_ostree-iso-x86_64-*-64bit": 20,
Make rpm-ostree tests generic, run on Silverblue and CoreOS This makes the two rpm-ostree tests written for IoT - overlaying and rebasing - work across all rpm-ostree-based flavors we currently test (IoT, CoreOS and Silverblue) and runs them on all those flavors. This requires some other changes. For the Workstation ostree installer update tests, we have install_default_update_ostree upload a disk image and run these tests on that image. That means install_default_update_ostree cannot use a scratch disk (as if we boot it with two disks but only upload one, the subsequent tests fail to boot, looking for the missing second disk), but its specified disk size should be large enough for all updates. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-12-06 22:41:56 +00:00
"fedora-Silverblue-dvd_ostree-iso-ppc64le-*-ppc64le": 50,
"fedora-Silverblue-dvd_ostree-iso-x86_64-*-64bit": 50
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"POSTINSTALL": "rpmostree_rebase",
"ROOT_PASSWORD": "weakpassword",
"+START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%",
"USER_LOGIN": "false"
}
},
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"secure_boot_fallback": {
"profiles": {
"fedora-IoT-dvd_ostree-iso-x86_64-*-64bit": 30,
"fedora-KDE-live-iso-x86_64-*-64bit": 30,
"fedora-Server-dvd-iso-x86_64-*-64bit": 30,
"fedora-Silverblue-dvd_ostree-iso-x86_64-*-64bit": 50,
"fedora-Workstation-live-iso-x86_64-*-64bit": 30,
"fedora-Workstation-live_osbuild-iso-x86_64-*-64bit": 60
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"POSTINSTALL": "_secure_boot_fallback",
"ROOT_PASSWORD": "weakpassword",
"+START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%",
"USER_LOGIN": "false"
}
},
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"server_cockpit_basic": {
"profiles": {
"fedora-Server-dvd-iso-aarch64-*-aarch64": 30,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 30,
"fedora-Server-dvd-iso-x86_64-*-64bit": 30
},
"settings": {
"+HDD_1": "disk_%MACHINE%_cockpit.qcow2",
"+START_AFTER_TEST": "server_cockpit_default",
"BOOTFROM": "c",
"POSTINSTALL": "server_cockpit_basic",
"ROOT_PASSWORD": "weakpassword",
"USER_LOGIN": "false"
}
},
"server_cockpit_default": {
"profiles": {
"fedora-Server-dvd-iso-aarch64-*-aarch64": 20,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 20,
"fedora-Server-dvd-iso-x86_64-*-64bit": 20
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"POSTINSTALL": "_setup_browser server_cockpit_default",
"ROOT_PASSWORD": "weakpassword",
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"STORE_HDD_1": "disk_%MACHINE%_cockpit.qcow2",
"USER_LOGIN": "false"
}
},
"server_cockpit_updates": {
"profiles": {
"fedora-Server-dvd-iso-x86_64-*-64bit": 30
},
"settings": {
"+HDD_1": "disk_%MACHINE%_cockpit.qcow2",
"+START_AFTER_TEST": "server_cockpit_default",
"BOOTFROM": "c",
Don't snapshot after wait_login tests (usually) We currently snapshot after every run of _console_wait_login or _graphical_wait_login, which means we snapshot *twice* on most update tests as those modules get run twice. However, we almost never use those snapshots. Snapshotting takes quite some time, and hits the disk pretty hard, so we should avoid it unless it is really needed. We only have a few modules that are not fatal (and so might use the snapshots), and most of those don't run after one of these tests, or run after a later module that's also a milestone. Best I can tell, only two test suites really need to use a snapshot from a login test: server_cockpit_updates and modularity_tests. To handle these and potential future cases, we'll add a new module that does nothing, but is marked 'milestone', so it will take a snapshot, and load that test after the login test if the var LOGIN_SNAPSHOT is set, and set that var for those two suites. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-12-07 23:24:02 +00:00
"LOGIN_SNAPSHOT": "1",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"POSTINSTALL": "server_cockpit_updates server_cockpit_autoupdate",
"ROOT_PASSWORD": "weakpassword",
"USER_LOGIN": "false"
}
},
"server_database_client": {
"profiles": {
"fedora-Server-dvd-iso-aarch64-*-aarch64": 30,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 30,
"fedora-Server-dvd-iso-x86_64-*-64bit": 30
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"NICTYPE": "tap",
"PARALLEL_WITH": "server_role_deploy_database_server",
"POSTINSTALL": "database_client",
Use 'test.openqa.fedoraproject.org' not 'domain.local' Using .local is apparently Bad Form because it's reserved for mDNS. However there doesn't appear to be any particularly Good Form for what to call a test domain you never want to exist outside of a closed system, apparently. Sigh. Let's try this. Includes a bump to disk_ks version because the kickstarts on that image also need to have this change applied. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-12-15 20:43:53 +00:00
"POST_STATIC": "172.16.2.105 dbclient.test.openqa.fedoraproject.org",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"ROOT_PASSWORD": "weakpassword",
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"USER_LOGIN": "false",
"WORKER_CLASS": "tap"
}
},
"server_filesystem_default": {
"profiles": {
"fedora-Server-dvd-iso-aarch64-*-aarch64": 20,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 20,
"fedora-Server-dvd-iso-x86_64-*-64bit": 20
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"POSTINSTALL": "server_filesystem_default",
"ROOT_PASSWORD": "weakpassword",
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"USER_LOGIN": "false"
}
},
"server_firewall_default": {
"profiles": {
"fedora-Server-dvd-iso-aarch64-*-aarch64": 20,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 20,
"fedora-Server-dvd-iso-x86_64-*-64bit": 20
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"POSTINSTALL": "server_firewall_default",
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"USER_LOGIN": "false"
}
},
"server_freeipa_replication_client": {
"profiles": {
Fix profile for FreeIPA replication tests on aarch64 Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-03-13 00:37:21 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 30,
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 20,
"fedora-Server-dvd-iso-x86_64-*-64bit": 20
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"NICTYPE": "tap",
"PARALLEL_WITH": "server_freeipa_replication_replica",
Add Samba AD tests This adds a Samba AD server test, and client enrolment tests via sssd, Cockpit and kickstart. Requires the matching createhdds commit to add the kickstart to the disk_ks image. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-07-19 23:41:21 +00:00
"POSTINSTALL": "realmd_join_sssd domain_client",
Use 'test.openqa.fedoraproject.org' not 'domain.local' Using .local is apparently Bad Form because it's reserved for mDNS. However there doesn't appear to be any particularly Good Form for what to call a test domain you never want to exist outside of a closed system, apparently. Sigh. Let's try this. Includes a bump to disk_ks version because the kickstarts on that image also need to have this change applied. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-12-15 20:43:53 +00:00
"POST_STATIC": "172.16.2.108 client005.test.openqa.fedoraproject.org",
Add Samba AD tests This adds a Samba AD server test, and client enrolment tests via sssd, Cockpit and kickstart. Requires the matching createhdds commit to add the kickstart to the disk_ks image. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-07-19 23:41:21 +00:00
"REALMD_DNS_SERVER_HOST": "ipa003.test.openqa.fedoraproject.org",
"REALMD_DNS_SERVER_IP": "172.16.2.107",
"REALMD_SERVER_MUTEX": "domain_replica_ready",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"ROOT_PASSWORD": "weakpassword",
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"USER_LOGIN": "false",
Move some tap job groups to new 'tap2' worker class This is intended to allow us to split the workload across multiple tap workers, as right now, sometimes we wind up in a situation where all non-tap jobs are done and the non-tap workers are sitting idle, but the poor tap worker has a backlog. This way the tap jobs for updates can be split across two worker hosts, which should help out. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-11-26 01:33:31 +00:00
"WORKER_CLASS": "tap2"
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
}
},
"server_freeipa_replication_master": {
"profiles": {
Fix profile for FreeIPA replication tests on aarch64 Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-03-13 00:37:21 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 30,
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 20,
"fedora-Server-dvd-iso-x86_64-*-64bit": 20
},
"settings": {
"BOOTFROM": "c",
"FREEIPA_REPLICA_MASTER": "1",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"NICTYPE": "tap",
"PARALLEL_CANCEL_WHOLE_CLUSTER": "0",
"POSTINSTALL": "role_deploy_domain_controller role_deploy_domain_controller_check",
Use 'test.openqa.fedoraproject.org' not 'domain.local' Using .local is apparently Bad Form because it's reserved for mDNS. However there doesn't appear to be any particularly Good Form for what to call a test domain you never want to exist outside of a closed system, apparently. Sigh. Let's try this. Includes a bump to disk_ks version because the kickstarts on that image also need to have this change applied. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-12-15 20:43:53 +00:00
"POST_STATIC": "172.16.2.106 ipa002.test.openqa.fedoraproject.org",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"ROOT_PASSWORD": "weakpassword",
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"USER_LOGIN": "false",
Move some tap job groups to new 'tap2' worker class This is intended to allow us to split the workload across multiple tap workers, as right now, sometimes we wind up in a situation where all non-tap jobs are done and the non-tap workers are sitting idle, but the poor tap worker has a backlog. This way the tap jobs for updates can be split across two worker hosts, which should help out. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-11-26 01:33:31 +00:00
"WORKER_CLASS": "tap2"
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
}
},
"server_freeipa_replication_replica": {
"profiles": {
Fix profile for FreeIPA replication tests on aarch64 Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-03-13 00:37:21 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 30,
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 20,
"fedora-Server-dvd-iso-x86_64-*-64bit": 20
},
"settings": {
"BOOTFROM": "c",
"FREEIPA_REPLICA": "1",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"NICTYPE": "tap",
"PARALLEL_CANCEL_WHOLE_CLUSTER": "0",
"PARALLEL_WITH": "server_freeipa_replication_master",
"POSTINSTALL": "realmd_join_sssd",
Use 'test.openqa.fedoraproject.org' not 'domain.local' Using .local is apparently Bad Form because it's reserved for mDNS. However there doesn't appear to be any particularly Good Form for what to call a test domain you never want to exist outside of a closed system, apparently. Sigh. Let's try this. Includes a bump to disk_ks version because the kickstarts on that image also need to have this change applied. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-12-15 20:43:53 +00:00
"POST_STATIC": "172.16.2.107 ipa003.test.openqa.fedoraproject.org",
Add Samba AD tests This adds a Samba AD server test, and client enrolment tests via sssd, Cockpit and kickstart. Requires the matching createhdds commit to add the kickstart to the disk_ks image. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-07-19 23:41:21 +00:00
"REALMD_DNS_SERVER_HOST": "ipa002.test.openqa.fedoraproject.org",
"REALMD_DNS_SERVER_IP": "172.16.2.106",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"ROOT_PASSWORD": "weakpassword",
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"USER_LOGIN": "false",
Move some tap job groups to new 'tap2' worker class This is intended to allow us to split the workload across multiple tap workers, as right now, sometimes we wind up in a situation where all non-tap jobs are done and the non-tap workers are sitting idle, but the poor tap worker has a backlog. This way the tap jobs for updates can be split across two worker hosts, which should help out. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-11-26 01:33:31 +00:00
"WORKER_CLASS": "tap2"
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
}
},
"server_realmd_join_kickstart": {
"profiles": {
"fedora-Server-dvd-iso-aarch64-*-aarch64": 20,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 20,
"fedora-Server-dvd-iso-x86_64-*-64bit": 20
},
"settings": {
"GRUB": "inst.ks=hd:vdb1:/freeipaclient.ks",
Add Samba AD tests This adds a Samba AD server test, and client enrolment tests via sssd, Cockpit and kickstart. Requires the matching createhdds commit to add the kickstart to the disk_ks image. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-07-19 23:41:21 +00:00
"HDD_2": "disk_ks_7.img",
"INSTALL_UNLOCK": "domain_server_ready",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"KICKSTART": "1",
"NICTYPE": "tap",
"NUMDISKS": "2",
"PARALLEL_WITH": "server_role_deploy_domain_controller",
Add Samba AD tests This adds a Samba AD server test, and client enrolment tests via sssd, Cockpit and kickstart. Requires the matching createhdds commit to add the kickstart to the disk_ks image. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-07-19 23:41:21 +00:00
"POSTINSTALL": "domain_client",
"ROOT_PASSWORD": "anaconda",
"USER_LOGIN": "false",
"WORKER_CLASS": "tap"
}
},
"server_realmd_join_kickstart_ad": {
"profiles": {
"fedora-Server-dvd-iso-aarch64-*-aarch64": 20,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 20,
"fedora-Server-dvd-iso-x86_64-*-64bit": 20
},
"settings": {
"GRUB": "inst.ks=hd:vdb1:/adclient.ks",
"HDD_2": "disk_ks_7.img",
"INSTALL_UNLOCK": "domain_server_ready",
"KICKSTART": "1",
"NICTYPE": "tap",
"NUMDISKS": "2",
"PARALLEL_WITH": "server_samba_domain_controller",
"POSTINSTALL": "domain_client",
"REALMD_ADMIN_USER": "administrator",
"REALMD_DOMAIN": "samdom.openqa.fedoraproject.org",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"ROOT_PASSWORD": "anaconda",
"USER_LOGIN": "false",
"WORKER_CLASS": "tap"
}
},
"server_remote_logging_client": {
"profiles": {
Enable remote logging tests on aarch64 Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-03-12 23:16:15 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 20,
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 20,
"fedora-Server-dvd-iso-x86_64-*-64bit": 20
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"NICTYPE": "tap",
"PARALLEL_WITH": "server_remote_logging_server",
"POSTINSTALL": "server_remote_logging_client",
Use 'test.openqa.fedoraproject.org' not 'domain.local' Using .local is apparently Bad Form because it's reserved for mDNS. However there doesn't appear to be any particularly Good Form for what to call a test domain you never want to exist outside of a closed system, apparently. Sigh. Let's try this. Includes a bump to disk_ks version because the kickstarts on that image also need to have this change applied. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-12-15 20:43:53 +00:00
"POST_STATIC": "172.16.2.113 rsyslogclient.test.openqa.fedoraproject.org",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"ROOT_PASSWORD": "weakpassword",
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"USER_LOGIN": "false",
"WORKER_CLASS": "tap"
}
},
"server_remote_logging_server": {
"profiles": {
Enable remote logging tests on aarch64 Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-03-12 23:16:15 +00:00
"fedora-Server-dvd-iso-aarch64-*-aarch64": 20,
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 20,
"fedora-Server-dvd-iso-x86_64-*-64bit": 20
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"NICTYPE": "tap",
"PARALLEL_CANCEL_WHOLE_CLUSTER": "0",
"POSTINSTALL": "server_remote_logging_server",
Use 'test.openqa.fedoraproject.org' not 'domain.local' Using .local is apparently Bad Form because it's reserved for mDNS. However there doesn't appear to be any particularly Good Form for what to call a test domain you never want to exist outside of a closed system, apparently. Sigh. Let's try this. Includes a bump to disk_ks version because the kickstarts on that image also need to have this change applied. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-12-15 20:43:53 +00:00
"POST_STATIC": "172.16.2.112 rsyslogserver.test.openqa.fedoraproject.org",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"ROOT_PASSWORD": "weakpassword",
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"USER_LOGIN": "false",
"WORKER_CLASS": "tap"
}
},
"server_role_deploy_database_server": {
"profiles": {
"fedora-Server-dvd-iso-aarch64-*-aarch64": 20,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 20,
"fedora-Server-dvd-iso-x86_64-*-64bit": 20
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"NICTYPE": "tap",
"PARALLEL_CANCEL_WHOLE_CLUSTER": "0",
"POSTINSTALL": "role_deploy_database_server",
Use 'test.openqa.fedoraproject.org' not 'domain.local' Using .local is apparently Bad Form because it's reserved for mDNS. However there doesn't appear to be any particularly Good Form for what to call a test domain you never want to exist outside of a closed system, apparently. Sigh. Let's try this. Includes a bump to disk_ks version because the kickstarts on that image also need to have this change applied. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-12-15 20:43:53 +00:00
"POST_STATIC": "172.16.2.104 db.test.openqa.fedoraproject.org",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"ROOT_PASSWORD": "weakpassword",
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"USER_LOGIN": "false",
"WORKER_CLASS": "tap"
}
},
"server_role_deploy_domain_controller": {
"profiles": {
"fedora-Server-dvd-iso-aarch64-*-aarch64": 20,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 20,
"fedora-Server-dvd-iso-x86_64-*-64bit": 20
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"NICTYPE": "tap",
"PARALLEL_CANCEL_WHOLE_CLUSTER": "0",
"POSTINSTALL": "role_deploy_domain_controller role_deploy_domain_controller_check",
Use 'test.openqa.fedoraproject.org' not 'domain.local' Using .local is apparently Bad Form because it's reserved for mDNS. However there doesn't appear to be any particularly Good Form for what to call a test domain you never want to exist outside of a closed system, apparently. Sigh. Let's try this. Includes a bump to disk_ks version because the kickstarts on that image also need to have this change applied. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-12-15 20:43:53 +00:00
"POST_STATIC": "172.16.2.100 ipa001.test.openqa.fedoraproject.org",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"ROOT_PASSWORD": "weakpassword",
Unify base tests across normal, Cloud and arm We have variant versions of several of the base tests which exist to account for differences in required variable settings to run essentially the same test in different situations. By twiddling the variables a little, including inventing a new variable defined in the flavors and substituted into the test suites so the same test suite can have a different START_AFTER_TEST when run on different flavors, I think we can unite them all and make this a lot simpler. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-10-30 22:21:49 +00:00
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"USER_LOGIN": "false",
"WORKER_CLASS": "tap"
}
},
Add Samba AD tests This adds a Samba AD server test, and client enrolment tests via sssd, Cockpit and kickstart. Requires the matching createhdds commit to add the kickstart to the disk_ks image. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-07-19 23:41:21 +00:00
"server_samba_domain_controller": {
"profiles": {
"fedora-Server-dvd-iso-aarch64-*-aarch64": 20,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 20,
"fedora-Server-dvd-iso-x86_64-*-64bit": 20
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"NICTYPE": "tap",
"PARALLEL_CANCEL_WHOLE_CLUSTER": "0",
"POSTINSTALL": "samba_domain_controller samba_domain_controller_check",
"POST_STATIC": "172.16.2.130 ad001.samdom.openqa.fedoraproject.org",
"ROOT_PASSWORD": "weakpassword",
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%",
"USER_LOGIN": "false",
"WORKER_CLASS": "tap"
}
},
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"support_server": {
"profiles": {
"fedora-Server-dvd-iso-aarch64-*-aarch64": 10,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 10,
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"fedora-Server-dvd-iso-x86_64-*-64bit": 10
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"BOOTFROM": "c",
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"HDD_1": "disk_f%CURRREL%_support_6_%ARCH%.qcow2",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"NICTYPE": "tap",
"NUMDISKS": "2",
"PARALLEL_CANCEL_WHOLE_CLUSTER": "0",
"POSTINSTALL": "_support_server",
Use 'test.openqa.fedoraproject.org' not 'domain.local' Using .local is apparently Bad Form because it's reserved for mDNS. However there doesn't appear to be any particularly Good Form for what to call a test domain you never want to exist outside of a closed system, apparently. Sigh. Let's try this. Includes a bump to disk_ks version because the kickstarts on that image also need to have this change applied. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-12-15 20:43:53 +00:00
"POST_STATIC": "172.16.2.110 support.test.openqa.fedoraproject.org",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"ROOT_PASSWORD": "weakpassword",
"TEST_TARGET": "NONE",
"USER_LOGIN": "false",
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"WORKER_CLASS": "tap"
}
},
"support_server_2": {
"profiles": {
"fedora-Server-dvd-iso-aarch64-*-aarch64": 10,
"fedora-Server-dvd-iso-ppc64le-*-ppc64le": 10,
"fedora-Server-dvd-iso-x86_64-*-64bit": 10
},
"settings": {
"BOOTFROM": "c",
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"HDD_1": "disk_f%CURRREL%_support_6_%ARCH%.qcow2",
Move most 'universal' tests to Server-dvd-iso The 'universal' flavor has been kinda pointless for some time now. It dates back to the earliest days of openQA, before Pungi 4 was a thing, when composes were very different; we only built a boot.iso and some live images nightly for Rawhide, these weren't even formally grouped as a 'compose' at all (fedfind had to invent the concept). The TCs/RCs had DVD installer images (not *Server* DVD, at the time, just a universal DVD installer). We wanted to run some tests on the DVD image if it was available, but we still wanted to run them for the nightlies, so we invented a whole mechanism for that - this 'universal' flavor, with some complicated logic in fedora_openqa which schedules universal on the 'best available' image it can find in the compose. All this is functionally obsolete now. All composes we test are now run through Pungi (except the live respins, but they aren't relevant here). In current config, the Server DVD is non-failable on x86_64 and aarch64, which means it will *always be there* - if it fails to build, the compose itself fails, so we won't test it. It's failable for ppc64le, but we don't care that much about ppc64le; I'm fine with these tests just not running if the Server DVD happens to fail in a ppc64le compose. As a cherry on top, some of the 'universal' tests aren't really universal anyway, they fail if you run them on a netinst (off the top of my head, all the NFS install tests are like this, as we use the ISO to populate the NFS share on the server end). So let's just move all the tests that actually need an installer image to the Server-dvd-iso flavor. Left over in the 'universal' flavor are upgrade tests, which don't need an ISO at all - they boot from hard disk images and run an upgrade using repos. We can change the scheduler logic to be more simple for these, and just always schedule them, with no ISO attached. We could even rename this flavor 'upgrade', but it might not be worth it. One slight complication is that the split happened to be helping us avoid too many tests in a single support_server cluster; we have a cluster of five support_server tests on Server-dvd-iso and five support_server tests on universal. I try to avoid the clusters getting too big as you need as many worker instances on at least one worker host as your largest cluster; if you don't have that many, the cluster's tests simply never get scheduled. Requiring folks to have at least ten worker instances on one host to run these tests is a bit of a big ask. So, to handle that, we create a support_server_2 and have the former universal tests use that one instead, so we'll have two separate clusters on Server-dvd-iso now. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-05-03 20:45:52 +00:00
"NICTYPE": "tap",
"NUMDISKS": "2",
"PARALLEL_CANCEL_WHOLE_CLUSTER": "0",
"POSTINSTALL": "_support_server",
"POST_STATIC": "172.16.2.120 support2.test.openqa.fedoraproject.org",
"ROOT_PASSWORD": "weakpassword",
"SUPPORT_PXE": "1",
"SUPPORT_ISCSI": "1",
"TEST_TARGET": "NONE",
"USER_LOGIN": "false",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"WORKER_CLASS": "tap"
}
},
add toolbox test case with basic func to create, list, start and stop
2023-06-23 10:06:00 +00:00
"toolbox": {
"profiles": {
Run toolbox test on KDE as well There's no obvious reason it'd ever give a different result on KDE vs. Workstation, but since we added a matrix box for it on both, we'd better run it on both. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-08-29 22:08:09 +00:00
"fedora-KDE-live-iso-x86_64-*-64bit": 40,
add toolbox test case with basic func to create, list, start and stop
2023-06-23 10:06:00 +00:00
"fedora-Workstation-live-iso-x86_64-*-64bit": 40,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Workstation-live_osbuild-iso-x86_64-*-64bit": 60,
add toolbox test case with basic func to create, list, start and stop
2023-06-23 10:06:00 +00:00
"fedora-Workstation-raw_xz-raw.xz-aarch64-*-aarch64": 40,
"fedora-CoreOS-colive-iso-x86_64-*-64bit": 40,
"fedora-Silverblue-dvd_ostree-iso-x86_64-*-64bit": 40
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"POSTINSTALL": "toolbox",
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%"
}
},
Add an 'unwanted packages' test, run on Workstation for now (#218) This adds a test that just fails if any one of a given list of unwanted packages is installed. This was a request for the Workstation edition from @catanzaro so I've just implemented it for Workstation so far, but it's designed to be easily extended to cover other subvariants too if we want. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2021-04-30 22:46:55 +00:00
"unwanted_packages": {
"profiles": {
"fedora-Workstation-live-iso-ppc64le-*-ppc64le": 50,
"fedora-Workstation-live-iso-x86_64-*-64bit": 50,
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-Workstation-live_osbuild-iso-x86_64-*-64bit": 60,
Rename tests and flavours as per review.
2021-12-07 10:30:21 +00:00
"fedora-Workstation-upgrade-x86_64-*-64bit": 40,
"fedora-Workstation-upgrade-aarch64-*-aarch64": 40,
Add an 'unwanted packages' test, run on Workstation for now (#218) This adds a test that just fails if any one of a given list of unwanted packages is installed. This was a request for the Workstation edition from @catanzaro so I've just implemented it for Workstation so far, but it's designed to be easily extended to cover other subvariants too if we want. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2021-04-30 22:46:55 +00:00
"fedora-Workstation-raw_xz-raw.xz-aarch64-*-aarch64": 52
},
"settings": {
"BOOTFROM": "c",
"HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"POSTINSTALL": "unwanted_packages",
"START_AFTER_TEST": "%DEPLOY_UPLOAD_TEST%"
}
},
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"upgrade_2_desktop": {
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"profiles": {
Run desktop upgrade tests on aarch64 (#220) Signed-off-by: Adam Williamson <awilliam@redhat.com>
2021-06-18 21:44:09 +00:00
"fedora-universal-x86_64-*-64bit": 40,
"fedora-universal-aarch64-*-aarch64": 40
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"BOOTFROM": "c",
"DESKTOP": "gnome",
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"HDD_1": "disk_f%UP2REL%_desktop_5_%ARCH%.qcow2",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"ROOT_PASSWORD": "weakpassword",
"TEST_TARGET": "COMPOSE",
"UPGRADE": "1",
"USER_LOGIN": "test",
"USER_PASSWORD": "weakpassword"
}
},
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"upgrade_2_desktop_encrypted": {
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"profiles": {
Run desktop upgrade tests on aarch64 (#220) Signed-off-by: Adam Williamson <awilliam@redhat.com>
2021-06-18 21:44:09 +00:00
"fedora-universal-x86_64-*-64bit": 40,
"fedora-universal-aarch64-*-aarch64": 40
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"BOOTFROM": "c",
"DESKTOP": "gnome",
"ENCRYPT_PASSWORD": "weakpassword",
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"HDD_1": "disk_f%UP2REL%_desktopencrypt_2_%ARCH%.qcow2",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"ROOT_PASSWORD": "weakpassword",
"TEST_TARGET": "COMPOSE",
"UPGRADE": "1",
"USER_LOGIN": "test",
"USER_PASSWORD": "weakpassword"
}
},
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"upgrade_2_kde": {
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"profiles": {
"fedora-universal-x86_64-*-64bit": 40
},
"settings": {
"BOOTFROM": "c",
"DESKTOP": "kde",
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"HDD_1": "disk_f%UP2REL%_kde_5_x86_64.qcow2",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"ROOT_PASSWORD": "weakpassword",
"TEST_TARGET": "COMPOSE",
"UPGRADE": "1",
"USER_LOGIN": "test",
"USER_PASSWORD": "weakpassword"
}
},
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"upgrade_2_minimal": {
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"profiles": {
"fedora-universal-aarch64-*-aarch64": 40,
"fedora-universal-ppc64le-*-ppc64le": 40,
"fedora-universal-x86_64-*-64bit": 40
},
"settings": {
"BOOTFROM": "c",
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"HDD_1": "disk_f%UP2REL%_minimal_4_%ARCH%.qcow2",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"ROOT_PASSWORD": "weakpassword",
"TEST_TARGET": "COMPOSE",
"UPGRADE": "1",
"USER_LOGIN": "false"
}
},
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"upgrade_2_minimal_bios": {
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"profiles": {
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-universal-x86_64-*-bios": 40
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"BOOTFROM": "c",
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"HDD_1": "disk_f%UP2REL%_minimal-bios_4_%ARCH%.qcow2",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"ROOT_PASSWORD": "weakpassword",
"TEST_TARGET": "COMPOSE",
"UPGRADE": "1",
"USER_LOGIN": "false"
}
},
"upgrade_2_realmd_client": {
"profiles": {
Enable two-release FreeIPA upgrade test on aarch64 too Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-03-12 23:19:29 +00:00
"fedora-universal-aarch64-*-aarch64": 30,
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"fedora-universal-x86_64-*-64bit": 30
},
"settings": {
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"+HDD_1": "disk_f%UP2REL%_server_4_%ARCH%.qcow2",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"BOOTFROM": "c",
"NICTYPE": "tap",
"PARALLEL_WITH": "upgrade_2_server_domain_controller",
Add Samba AD tests This adds a Samba AD server test, and client enrolment tests via sssd, Cockpit and kickstart. Requires the matching createhdds commit to add the kickstart to the disk_ks image. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-07-19 23:41:21 +00:00
"POSTINSTALL": "_setup_browser freeipa_webui freeipa_password_change domain_client",
Use 'test.openqa.fedoraproject.org' not 'domain.local' Using .local is apparently Bad Form because it's reserved for mDNS. However there doesn't appear to be any particularly Good Form for what to call a test domain you never want to exist outside of a closed system, apparently. Sigh. Let's try this. Includes a bump to disk_ks version because the kickstarts on that image also need to have this change applied. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-12-15 20:43:53 +00:00
"POST_STATIC": "172.16.2.103 client003.test.openqa.fedoraproject.org",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"PREUPGRADE": "realmd_join_sssd",
"ROOT_PASSWORD": "weakpassword",
"TEST_TARGET": "COMPOSE",
"UPGRADE": "1",
"USER_LOGIN": "false",
"WORKER_CLASS": "tap"
}
},
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"upgrade_2_server": {
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"profiles": {
"fedora-universal-aarch64-*-aarch64": 40,
"fedora-universal-ppc64le-*-ppc64le": 40,
"fedora-universal-x86_64-*-64bit": 40
},
"settings": {
"BOOTFROM": "c",
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"HDD_1": "disk_f%UP2REL%_server_4_%ARCH%.qcow2",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"ROOT_PASSWORD": "weakpassword",
"TEST_TARGET": "COMPOSE",
"UPGRADE": "1",
"USER_LOGIN": "test",
"USER_PASSWORD": "weakpassword"
}
},
"upgrade_2_server_domain_controller": {
"profiles": {
Enable two-release FreeIPA upgrade test on aarch64 too Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-03-12 23:19:29 +00:00
"fedora-universal-aarch64-*-aarch64": 30,
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"fedora-universal-x86_64-*-64bit": 30
},
"settings": {
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"+HDD_1": "disk_f%UP2REL%_server_4_%ARCH%.qcow2",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"BOOTFROM": "c",
"NICTYPE": "tap",
"PARALLEL_CANCEL_WHOLE_CLUSTER": "0",
"POSTINSTALL": "role_deploy_domain_controller_check",
Use 'test.openqa.fedoraproject.org' not 'domain.local' Using .local is apparently Bad Form because it's reserved for mDNS. However there doesn't appear to be any particularly Good Form for what to call a test domain you never want to exist outside of a closed system, apparently. Sigh. Let's try this. Includes a bump to disk_ks version because the kickstarts on that image also need to have this change applied. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-12-15 20:43:53 +00:00
"POST_STATIC": "172.16.2.100 ipa001.test.openqa.fedoraproject.org",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"PREUPGRADE": "role_deploy_domain_controller",
"ROOT_PASSWORD": "weakpassword",
"TEST_TARGET": "COMPOSE",
"UPGRADE": "1",
"USER_LOGIN": "false",
"WORKER_CLASS": "tap"
}
},
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"upgrade_desktop": {
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"profiles": {
Rename tests and flavours as per review.
2021-12-07 10:30:21 +00:00
"fedora-Workstation-upgrade-x86_64-*-64bit": 30,
"fedora-Workstation-upgrade-aarch64-*-aarch64": 40
Add a new flavour to test upgrade postinstall tests.
2021-11-29 08:27:58 +00:00
},
"settings": {
"BOOTFROM": "c",
"DESKTOP": "gnome",
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"HDD_1": "disk_f%UP1REL%_desktop_5_%ARCH%.qcow2",
Add a new flavour to test upgrade postinstall tests.
2021-11-29 08:27:58 +00:00
"STORE_HDD_1": "disk_%FLAVOR%_%MACHINE%.qcow2",
"ROOT_PASSWORD": "weakpassword",
"TEST_TARGET": "COMPOSE",
"UPGRADE": "1",
"USER_LOGIN": "test",
"USER_PASSWORD": "weakpassword"
}
},
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"upgrade_desktop_encrypted_64bit": {
"profiles": {
Run desktop upgrade tests on aarch64 (#220) Signed-off-by: Adam Williamson <awilliam@redhat.com>
2021-06-18 21:44:09 +00:00
"fedora-universal-x86_64-*-64bit": 30,
"fedora-universal-aarch64-*-aarch64": 40
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"BOOTFROM": "c",
"DESKTOP": "gnome",
"ENCRYPT_PASSWORD": "weakpassword",
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"HDD_1": "disk_f%UP1REL%_desktopencrypt_2_%ARCH%.qcow2",
Bump retry count on some flaky tests The silverblue tests are flaky because of https://github.com/fedora-silverblue/issue-tracker/issues/548 . The desktop_upgrade_encrypted test is flaky on Rawhide (so, when booting from F40 initially) since we switched to UEFI, not sure if it's because of UEFI somehow or just a timing coincidence. Am going to look into it, but for now this should save lots of manual restarting. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-04-05 14:59:42 +00:00
"RETRY": "2",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"ROOT_PASSWORD": "weakpassword",
"TEST_TARGET": "COMPOSE",
"UPGRADE": "1",
"USER_LOGIN": "test",
"USER_PASSWORD": "weakpassword"
}
},
Add the graphical upgrade tests. This PR builds on some elements of the current upgrade process, such as upgrade_boot, upgrade_preinstall, upgrade_postinstall, but replaces the upgrade_run with graphical_upgrade_run to use graphical methods to upgrade the system. This would not be possible without necessary settings, that are performed by graphical_upgrade_prerequisites. Works for both Gnome and KDE.
2023-12-18 13:38:19 +00:00
"upgrade_desktop_graphical": {
"profiles": {
"fedora-universal-x86_64-*-64bit": 30,
"fedora-universal-aarch64-*-aarch64": 40
},
"settings": {
"BOOTFROM": "c",
"DESKTOP": "gnome",
"HDD_1": "disk_f%UP1REL%_desktop_5_%ARCH%.qcow2",
"ROOT_PASSWORD": "weakpassword",
"TEST_TARGET": "COMPOSE",
"UPGRADE": "1",
"GUI_UPGRADE": "1",
"USER_LOGIN": "test",
"USER_PASSWORD": "weakpassword"
}
},
"upgrade_2_desktop_graphical": {
"profiles": {
"fedora-universal-x86_64-*-64bit": 30,
"fedora-universal-aarch64-*-aarch64": 40
},
"settings": {
"BOOTFROM": "c",
"DESKTOP": "gnome",
"HDD_1": "disk_f%UP2REL%_desktop_5_%ARCH%.qcow2",
"ROOT_PASSWORD": "weakpassword",
"TEST_TARGET": "COMPOSE",
"UPGRADE": "1",
"GUI_UPGRADE": "1",
"USER_LOGIN": "test",
"USER_PASSWORD": "weakpassword"
}
},
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"upgrade_kde": {
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"profiles": {
"fedora-universal-x86_64-*-64bit": 30
},
"settings": {
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"+HDD_1": "disk_f%UP1REL%_kde_5_x86_64.qcow2",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"BOOTFROM": "c",
"DESKTOP": "kde",
"ROOT_PASSWORD": "weakpassword",
"TEST_TARGET": "COMPOSE",
"UPGRADE": "1",
"USER_LOGIN": "test",
"USER_PASSWORD": "weakpassword"
}
},
Add the graphical upgrade tests. This PR builds on some elements of the current upgrade process, such as upgrade_boot, upgrade_preinstall, upgrade_postinstall, but replaces the upgrade_run with graphical_upgrade_run to use graphical methods to upgrade the system. This would not be possible without necessary settings, that are performed by graphical_upgrade_prerequisites. Works for both Gnome and KDE.
2023-12-18 13:38:19 +00:00
"upgrade_kde_graphical": {
"profiles": {
"fedora-universal-x86_64-*-64bit": 30
},
"settings": {
"+HDD_1": "disk_f%UP1REL%_kde_5_x86_64.qcow2",
"BOOTFROM": "c",
"DESKTOP": "kde",
"ROOT_PASSWORD": "weakpassword",
"TEST_TARGET": "COMPOSE",
"UPGRADE": "1",
"GUI_UPGRADE": "1",
"USER_LOGIN": "test",
"USER_PASSWORD": "weakpassword"
}
},
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"upgrade_minimal": {
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"profiles": {
"fedora-universal-aarch64-*-aarch64": 30,
"fedora-universal-ppc64le-*-ppc64le": 30,
"fedora-universal-x86_64-*-64bit": 30
},
"settings": {
"BOOTFROM": "c",
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"HDD_1": "disk_f%UP1REL%_minimal_4_%ARCH%.qcow2",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"ROOT_PASSWORD": "weakpassword",
"TEST_TARGET": "COMPOSE",
"UPGRADE": "1",
"USER_LOGIN": "false"
}
},
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"upgrade_minimal_bios": {
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"profiles": {
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"fedora-universal-x86_64-*-bios": 30
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
},
"settings": {
"BOOTFROM": "c",
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"HDD_1": "disk_f%UP1REL%_minimal-bios_4_%ARCH%.qcow2",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"ROOT_PASSWORD": "weakpassword",
"TEST_TARGET": "COMPOSE",
"UPGRADE": "1",
"USER_LOGIN": "false"
}
},
"upgrade_realmd_client": {
"profiles": {
Enable FreeIPA replica and upgrade tests on aarch64 Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-03-12 23:17:09 +00:00
"fedora-universal-aarch64-*-aarch64": 30,
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"fedora-universal-ppc64le-*-ppc64le": 30,
"fedora-universal-x86_64-*-64bit": 30
},
"settings": {
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"+HDD_1": "disk_f%UP1REL%_server_4_%ARCH%.qcow2",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"BOOTFROM": "c",
Give FreeIPA upgrade tests 3 hours to run These can take a while. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-10-24 19:53:22 +00:00
"MAX_JOB_TIME": "10800",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"NICTYPE": "tap",
"PARALLEL_WITH": "upgrade_server_domain_controller",
Add Samba AD tests This adds a Samba AD server test, and client enrolment tests via sssd, Cockpit and kickstart. Requires the matching createhdds commit to add the kickstart to the disk_ks image. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2023-07-19 23:41:21 +00:00
"POSTINSTALL": "_setup_browser freeipa_webui freeipa_password_change domain_client",
Use 'test.openqa.fedoraproject.org' not 'domain.local' Using .local is apparently Bad Form because it's reserved for mDNS. However there doesn't appear to be any particularly Good Form for what to call a test domain you never want to exist outside of a closed system, apparently. Sigh. Let's try this. Includes a bump to disk_ks version because the kickstarts on that image also need to have this change applied. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-12-15 20:43:53 +00:00
"POST_STATIC": "172.16.2.103 client003.test.openqa.fedoraproject.org",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"PREUPGRADE": "realmd_join_sssd",
"ROOT_PASSWORD": "weakpassword",
"TEST_TARGET": "COMPOSE",
"UPGRADE": "1",
"USER_LOGIN": "false",
Move some tap job groups to new 'tap2' worker class This is intended to allow us to split the workload across multiple tap workers, as right now, sometimes we wind up in a situation where all non-tap jobs are done and the non-tap workers are sitting idle, but the poor tap worker has a backlog. This way the tap jobs for updates can be split across two worker hosts, which should help out. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-11-26 01:33:31 +00:00
"WORKER_CLASS": "tap2"
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
}
},
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"upgrade_server": {
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"profiles": {
"fedora-universal-aarch64-*-aarch64": 30,
"fedora-universal-ppc64le-*-ppc64le": 30,
"fedora-universal-x86_64-*-64bit": 30
},
"settings": {
"BOOTFROM": "c",
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"HDD_1": "disk_f%UP1REL%_server_4_%ARCH%.qcow2",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"ROOT_PASSWORD": "weakpassword",
"TEST_TARGET": "COMPOSE",
"UPGRADE": "1",
"USER_LOGIN": "test",
"USER_PASSWORD": "weakpassword"
}
},
"upgrade_server_domain_controller": {
"profiles": {
Enable FreeIPA replica and upgrade tests on aarch64 Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-03-12 23:17:09 +00:00
"fedora-universal-aarch64-*-aarch64": 30,
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"fedora-universal-ppc64le-*-ppc64le": 30,
"fedora-universal-x86_64-*-64bit": 30
},
"settings": {
Make UEFI testing the default, add Secure Boot testing This essentially inverts the x86_64 machines so that '64bit' is UEFI and instead of a variant 'uefi' machine we have a variant 'bios' machine that is BIOS. The point is to make UEFI testing the default. We also enable Secure Boot in the UEFI testing, and add a test of UEFI fallback booting on various products. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2024-03-19 23:52:00 +00:00
"+HDD_1": "disk_f%UP1REL%_server_4_%ARCH%.qcow2",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"BOOTFROM": "c",
Give FreeIPA upgrade tests 3 hours to run These can take a while. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-10-24 19:53:22 +00:00
"MAX_JOB_TIME": "10800",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"NICTYPE": "tap",
"PARALLEL_CANCEL_WHOLE_CLUSTER": "0",
"POSTINSTALL": "role_deploy_domain_controller_check",
Use 'test.openqa.fedoraproject.org' not 'domain.local' Using .local is apparently Bad Form because it's reserved for mDNS. However there doesn't appear to be any particularly Good Form for what to call a test domain you never want to exist outside of a closed system, apparently. Sigh. Let's try this. Includes a bump to disk_ks version because the kickstarts on that image also need to have this change applied. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-12-15 20:43:53 +00:00
"POST_STATIC": "172.16.2.100 ipa001.test.openqa.fedoraproject.org",
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
"PREUPGRADE": "role_deploy_domain_controller",
"ROOT_PASSWORD": "weakpassword",
"TEST_TARGET": "COMPOSE",
"UPGRADE": "1",
"USER_LOGIN": "false",
Move some tap job groups to new 'tap2' worker class This is intended to allow us to split the workload across multiple tap workers, as right now, sometimes we wind up in a situation where all non-tap jobs are done and the non-tap workers are sitting idle, but the poor tap worker has a backlog. This way the tap jobs for updates can be split across two worker hosts, which should help out. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2022-11-26 01:33:31 +00:00
"WORKER_CLASS": "tap2"
Add a whole intermediate template format ('FIF') and tools I and @lruzicka (and I think @jskladan and @jsedlak and @michelmno and everyone else who's ever touched it...) are being gradually driven nuts by manually editing the test templates. The bigger the files get the more awkward it is to keep them straight and be sure we're doing it right. Upstream doesn't do things the same way we do (they mostly edit in the web UI and dump to file for the record), but we do still think making changes in the repo and posting to the web UI is the right way around to do it, we just wish the format was saner. Upstream has actually recently introduced a YAML-based approach to storing job templates which tries to condense things a bit, and you can dump to that format with dump-templates --json, but @lruzicka and I agree that that format is barely better for hand editing in a text editor than the older one our templates currently use. So, this commit introduces...Fedora Intermediate Format (FIF) - an alternative format for representing job templates - and some tools for working with it. It also contains our existing templates in this new format, and removes the old template files. The format is documented in the docstrings of the tools, but briefly, it keeps Machines, Products and TestSuites but improves their format a bit (by turning dicts-of-lists into dicts-of- dicts), and adds Profiles, which are combinations of Machines and Products. TestSuites can indicate which Profiles they should be run on. The intermediate format converter (`fifconverter`) converts existing template data (in JSON format; use tojson.pm to convert our perl templates to JSON) to the intermediate format and writes it out. As this was really intended only for one-time use (the idea is that after one-time conversion, we will edit the templates in the intermediate format from now on), its operation is hardcoded and relies on specific filenames. The intermediate format loader (`fifloader`) generates JobTemplates from the TestSuites and Profiles, reverses the quality-of-life improvements of the intermediate format, and produces template data compatible with the upstream loader, then can write it to disk and/or call the upstream loader directly. The check script (`fifcheck`) runs existing template data through both the converter and the loader, then checks that the result is equivalent to the input. Again this was mostly written for one- time use so is fairly rough and hard-coded, but I'm including it in the commit so others can check the work and so on. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-23 14:20:10 +00:00
}
}
}
Re-enable memory_check test (on Everything, with WS packages) We were only running this test on the Workstation boot ISO... then that was removed, and so we actually never ran this test at all any more. We should run it on at least one image as check- compose uses the output to check whether installer memory usage has increased. I initially ran it on Workstation as that installs the most packages; so let's run it on Everything but use the Workstation package set. Signed-off-by: Adam Williamson <awilliam@redhat.com>
2020-01-25 15:11:17 +00:00
}
Reference in New Issue Copy Permalink