Open LecrisUT opened 2 months ago
Hopefully https://tmt.readthedocs.io/en/stable/code/plugin-introduction.html answers the 'how to write plugin' questions. I don't see the framework documented, so this is https://github.com/teemtee/tmt/blob/main/tmt/frameworks/__init__.py
Each plugin has 'require' which is added to the other (test) require and installed during 'prepare' step on the guest.
tldr; it isn't in .fmf
files but you need to have installed on the runner.
Indeed, WRT test framework https://github.com/teemtee/tmt/blob/main/tmt/frameworks/__init__.py#L38 (https://tmt.readthedocs.io/en/stable/code/autodocs/tmt.frameworks.html#tmt.frameworks.TestFramework) and e.g. https://github.com/teemtee/tmt/blob/main/tmt/frameworks/shell.py
WRT prepare plugin, any would work as an example, e.g. https://github.com/teemtee/tmt/blob/main/tmt/steps/prepare/shell.py
Thanks, what I had in mind is to have a requirement.txt
section for the fmf
files where the plugins can auto-magically be pulled. Probably always on the plans
level. Since they all have to be python based, we can just call pip
internally to get the dependencies, with probably a safe-guard that the automation only occurs in venv
, and outside of it there is a print-out of where/how to get the dependency from pypi.
One complication in that approach is how to refresh the python environment to load the newly installed packages :thinking:
'auto-magicall' pull would be interesting to have, but I'm afraid that for production CI it will be disabled (or allow-listed) anyway so I'm not sure that it is worth pursuing right now. Lets' start with cmake as a plugin which is pip installed manually (read: on workers as TF or actions or ..)
We have 2 plugins internally and frankly speaking it is pain to keep them working with 3 versions of tmt - the released (pypi, fedora), the main branch (copr teemtee/tmt for early adopters) and PR which modifies (read: breaks) API.
Code of those plugins can have lot of hasattr
if/else if some release is particular heavy with development.
With that said, having it this repo is easier for the maintainer of such plugin.
I have started the repo: https://github.com/LecrisUT/tmt-cmake and I'll see how it goes. First step is to get the plugin to be loaded and detected when tmt plans show
I want to sketch out some ideas for making tmt-cmake plugin:
.fmf
files, how to overwrite it via an editable-like installation, how to minimize coupling with upstreamplan.prepare
plugin: runs a configure-build (maybe also install) preset/traditional workflowtest.framework
plugin: runctest
for a build environment defined in previous featureplan.discover
plan.discover
plugin: convert test names andctest
labels to tmt tests and tagsplan.report
plugin: recover junit results from ctest and forward it downctest --build-and-test
. E.g. thic could parse the build stdout/stderr, build folder artifacts, etc. as part of a regression test and pass it to something like beakerlib.