-
Notifications
You must be signed in to change notification settings - Fork 731
Integrating rule check into Travis CI #1599
Description
Extending the continuous integration tests
We discussed about the more checks before, and now @csanders-git asked again, I would like to start to design the implementation.
Description
The main goal is to extend the Travis CI with some more tests, which did not exist before, and helps to keep the well formed text structure of the whole rule set. Ideas have come before, now I try to collect and organize them, and please help me to make the finally plan.
To make the new checks, I'ld like to use msc_pyparser to build the AST, write the abstract structure, and re-generate the rule set. Between these two steps, I'ld like to run the test cases, so the main line:
- generate structures
- run checks
- write the parsed structure
Let's see the function of each steps!
-
For a correct work it's necessary that the rule sets must be syntactically (and of course lexically) correct. Now the secrule_parser from @fzipi is a good tool, but any case sensitive differences could break the check. I don't know that could be changed or not, but I think we can leave it in the CI.
-
In this step, I got these ideas from you:
- case-sensitive check for configuration directives, variables, operators, and actions
- order check for actions - see the related wiki and doc
- occurrence of mandatory tags, actions:
verparanoia-level
- collect referred but non-existent tags (
ctl:ruleRemoveByTag=TAGbut TAG not exists) - and many other ideas what you have
- Although this may not seems important, but the writer of parser class is very strict. I mean it uses predefined (hard-coded) indentations, leading and trailing spaces (eg. before the trailing
\at the end of lines, and so on...), so with help of the re-generated rule set, we can use a simplediffto detect the hidden (or missing) spaces, tabs and other annoying characters.
There is one more type of checks, which isn't important and doesn't have any additional worth. We can check many other things, eg. uniqueness of rule ID's, mandatory and optional arguments at variables, operators and actions - but (and that's why I wrote that this isn't a plus worth) this kind of errors are discoverable, because the Apache inside the Travis loads the rules, and it catches these errors.
I hope that this will helps you to get started the ideas.