The idea is to hack os-autoinst-distri-opensuse infrastucture and explore design patterns that can fit. The end point of this is to restructure the framework in such a way that the main-common.pm is more efficient, functional and readable.
Looking for hackers with the skills:
This project is part of:
Hack Week 19
Activity
Comments
-
almost 5 years ago by bmwiedemann | Reply
For the record, my original design can still be seen in https://github.com/os-autoinst/os-autoinst/tree/v1/consoletest.d
There, test modules would be evaluated in order and their is_applicable method would decide if it needs to run in the current scenario.
That also had downsides: it was hard to skip a larger number of modules, so to help there, there were base classes like https://github.com/os-autoinst/os-autoinst/blob/v1/autoinstallstep.pm that implemented is_applicable for all their subclasses. A bit better, but still not really nice.
-
almost 5 years ago by bmwiedemann | Reply
But on the plus side, you could just symlink a new test module into a directory and it would run as part of the next sequence. And any syntax error in a module would just cause this one module to be skipped.
-
almost 5 years ago by ybonatakis | Reply
https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/9545 So far the design seems to work for a single test suite. I am trying to add more and test them. Also i need to move the factory classes out of the main.pm.
-
almost 5 years ago by okurz | Reply
@bmwiedemann Great to see you mention the original idea which I think is still valid but of course still has the caveats you presented :)
-
almost 5 years ago by ybonatakis | Reply
Propably not the right place to put it but i uploaded a small presentation Hackweek19pdf
-
almost 5 years ago by ybonatakis | Reply
Final update of the status of the project. The factory design pattern has been applied. The Factory class is able to pick the correct subclass of the TestSuiteInterface.pm (which all the test suites should inherit from). The main.pm has only to initialize the factory and ask from the whatever test to run the proper scheduler for the ongoing test suite. A following up development should expand (adding the abstraction for) the design to add the modules of each test suite based on other factors, like ARCH.
Similar Projects
Create object oriented API for perl's YAML::XS module, with YAML 1.2 Support by tinita
Description
YAML::XS is a binding to libyaml and already quite old, but the most popular YAML module for perl. There are two main issues:
- It uses global package variables to influence behaviour.
- It didn't implement the loading of types like numbers and booleans according to the YAML spec (neither 1.1 nor 1.2).
Goals
Create a new interface which works object oriented. Currently YAML::XS exports a list of functions.
- The new API will allow to create a YAML::XS object containing configuration influencing the behaviour of loading and dumping.
- It keeps the libyaml parser and emitter structs in memory, so repeated calls can save the creation of those structs
- It will by default implement the YAML 1.2 Core Schema, so it is compatible to other YAML processors in perl and in other languages
- If I have time, I would like to add the merge
<<key feature as an option. We could then use it in openQA as a replacement for YAML::PP to be faster.
I already created a proof of concept with a minimal functionality some weeks before this HackWeek.
Resources
- Work is currently happening on the oop branch
- Experimental release waiting for user feedback: https://github.com/perlpunk/yaml-libyaml-pm/releases
- Diff