teemtee
Allow filtering based on the node name
Include a special key fmf-name in the data dictionary during the filter execution so that it's possible to filter based on the fmf node name as well.
Summary from the hacking session: Use no key for search by fmf node name. Example:
/tests/core & tag:quick
So we don't have to invent/decide any name ;-)
@psss Is the "/tests/core & tag:quick" possible with current PR? It doesn't seem so. Also adding a unit test and similar example do the pydoc fmf.filter will be useful.
This actually brings some issues. See, right now fmf filter is unable parse regular expressions that are quite common and that I assume people will likely be using (there is already a misplaced issue in tmt project for this. This problem is solvable[*] under the assumption that keys are always used. But once this PR is merged this assumption is gone.
[*] Using a positive lookahead assertion as follows:
# At least one clause must be true
return any([check_clause(clause)
for clause in re.split(r"\s*\|\s*(?=[^|]*:)", filter)])
Once you have | in a regexp the only way to distinguish it from proper disjunction is to to check that some key follows it. If not then it must be a part of value of the last key. Same approach can be applied to identifying a proper conjunction. With that you can already use pretty powerful regular expressions as values (you still need to avoid using both | and : in you regexp, but probability of that is fairly low IMO). Allowing not to have a key will break this logic.
Once you have | in a regexp the only way to distinguish it from proper disjunction is to to check that some key follows it. If not then it must be a part of value of the last key. Same approach can be applied to identifying a proper conjunction. With that you can already use pretty powerful regular expressions as values (you still need to avoid using both | and : in you regexp, but probability of that is fairly low IMO). Allowing not to have a key will break this logic.
With escaping it is clear whether | is part of filter syntax or regexp (\|). Escaping of ':' is already supported (driven by colon used in module nsv strings used as component value), escaping '&' and '|' are planned in this release.
@psss Is the "/tests/core & tag:quick" possible with current PR? It doesn't seem so. Also adding a unit test and similar example do the pydoc fmf.filter will be useful.
Implemented and documented. @lukaszachy, please review.