Day5 is joyful

Back

Today I’d like to think about the future for the achieved results.

DONE

Finding home

The purpose of this hackweek project is to create some openQA tests for Wezterm. This project is more oriented to provide a test tool to the Wezterm project than validating that one Wezterm version can at least start in all the openSUSE Tumbleweed versions. I’d like to achieve “Test all the Wezterm features possibly in more than one linux distro”

Keeping that in mind, what I’m not sure about is where to “place” them?

Let say that I can start from creating a PR in os-autoinst-distri-opensuse and os-autoinst-needles-opensuse for the test code and needles that I created this week. And let say that one day in the future they are approved and committed :slightly_smiling_face: How can I let Mr Wetz (the Wezterm developer) to “use” them? Is there a way that I can think to add to the wezterm github action a trigger to let the tests to run… or maybe a link (bot) to obs to check the wezterm obs package? How can I make my hackweek effort valuable for the Wezterm community?

OpenQA distribution

As the goal is to have a non-openSUSE-specific tests, a possible approach is to create a new distribution with just the code that I need. Distribution here does not mean a linux distribution :grin: : it means test distribution, like os-autoinst-distri-opensuse or os-autoinst-distri-example.\

Why not to directly commit the test code in os-autoinst-distri-opensuse? Well, adding tests code there means that anyone can use them as other tests in that repo are used within openqa.opensuse.org. Potentially doing so, it is possible to add a CI rules in the Wezterm project so that any pull request in the wezterm repo runs according tests on openqa.opensuse.org. But those tests and infrastructure are more focused in validate openSUSE than a particular application running on it and os-autoinst-distri-opensuse is more tailored towards running tests for packages that are installable by package, not for development versions of applications that are just within a pull request.

Probably a separate test distribution would be cleaner, like based on os-autoinst-distri-example with just what is needed.

The challenge in not using os-autoinst-distri-opensuse is that many helpers might be considered missing. The os-autoinst test API only offers what every computer has, not necessarily all that is needed for “a Linux application”

So a distribution means:

• a dedicated repository (it probably has not necessary to belong to the os-autoinst github organization/user/..)
• a folder structure in the repository (os-autoinst-distri-example as skeleton)
• I probably need to feel the gap of all the good stuff that I’m using from testapi

In order to use my custom test distribution on my openQA instance* I need:

• to have an openQA instance that clone this repo in its /var/lib/openqa/tests/
• from openQA you would set the “DISTRI” variable pointing to a folder name in /var/lib/openqa/tests, so e.g. if I clone os-autoinst-distri-wezterm into a folder “wezterm” just set DISTRI=wezterm.

As alternative it is possible to specify the git URL directly within the CASEDIR variable, see backend_vars for explanation of the complete format. This is also what openqa-clone-custom-git-refspec does.

No openQA

It is also possible not to have a full openQA instance. Inspired by:

• this Kalikiana’s post.
• this Oliver’s article.
• ci-isotovideo.yml Github action powered by test_isotovideo script.
• isotovideo-action.yml

I created an example repo isotovideo-action that directly use isotovideo in a github action. About using a custom test distribution with this approach: openQA sets CASEDIR from the DISTRI variable so it is possible to set CASEDIR also directly.

TODO

Hackweek webpage

• Create a new separate page where to start developing a hackweek presentation (reveal.js maybe)