223 is introducing mark-leaf as a mechanism to make a directory fmf file into a leaf, e.g. with /root/leaf_test (e.g. from /root/leaf_test.fmf) it allows /root to also be a valid test. This proposal is to also support the opposite, i.e. if we have a file /root.fmf do not expand it as a leaf.
This is relevant when we consider graft mechanism in #99, and specifically when one of the trees is virtual (generated from discover step). E.g. if the generated tree is like /root/leaf_test_A, /root/leaf_test_B, we could have a /root.fmf file such that it is inherited in all leaf_test_*. The issue is that currently /root would be considered as a leaf, and can affect tmt lint or define dummy tests for other discover steps. Having this mechanism will effectively hide the /root base, until it is expanded by leaves (through graft mechanism).
223 is introducing
mark-leafas a mechanism to make a directoryfmffile into a leaf, e.g. with/root/leaf_test(e.g. from/root/leaf_test.fmf) it allows/rootto also be a valid test. This proposal is to also support the opposite, i.e. if we have a file/root.fmfdo not expand it as a leaf.This is relevant when we consider
graftmechanism in #99, and specifically when one of the trees is virtual (generated fromdiscoverstep). E.g. if the generated tree is like/root/leaf_test_A,/root/leaf_test_B, we could have a/root.fmffile such that it is inherited in allleaf_test_*. The issue is that currently/rootwould be considered as a leaf, and can affecttmt lintor define dummy tests for otherdiscoversteps. Having this mechanism will effectively hide the/rootbase, until it is expanded by leaves (throughgraftmechanism).