-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: explicitly check more than just .bb/.bbappend #607
Comments
So we are talking mainly about But if we are talking about arbitrary files, I guess the current grouping algorithm is ill prepared for that and I can't imagine a way to do it without the knowledge of a full bitbake build, so I tend to be in favor of adding Please confirm that |
.conf would certainly be enough for now. I doubt anyone cares to lint a .inc that isn't included, for example. I could, however, picture a layer that provides optional bbclasses to be added by the user to INHERIT in local.conf, so it's not explicitly inherited by any recipes out of the box. I think you'd want to be able to lint arbitrary classes as well to cover that case. |
I started working on the issue, but it looks like it's more complicated than I initially thought. Only limitation so far (that I can see) is that there won't be support for @kergoth btw do for happen to have an example check that you want to see in the linter, that explicitly only should be applied to |
That makes sense regarding local.conf and site.conf. Regarding default rules, the ones I'm using here are specific to how we're doing things (and are actually against an isar-based layer, not oe), but I can think of a number of possibilities regarding ensuring layer.conf, machine .conf, and distro .conf are well behaved. For example, one could check that the boundaries between machine, distro, and image axes are properly maintained. That is, no machine should be setting DISTRO_FEATURES, or vice versa, for example. That's off the top of my head, but there are probably others regarding well behaved configs. A layer.conf probably shouldn't be mucking about with image variables, or distro, or machine. We could check to verify that the layer.conf adds to BBFILE_COLLECTIONS and defines the expected layer variables too. |
to the run groups in the way bitbake does it as well. The order of conf files is the following - layer.conf - machine configs - distro configs Closes #607 Signed-off-by: Konrad Weihmann <[email protected]>
to check on discouraged variables in distro configurations Relates to #607 Signed-off-by: Konrad Weihmann <[email protected]>
to check that only layer.conf specific variables are set in a layer.conf Relates to #607 Signed-off-by: Konrad Weihmann <[email protected]>
to check for discouraged variables in a machine conf Relates to #607 Signed-off-by: Konrad Weihmann <[email protected]>
@kergoth I started to slowly push the requested changes. |
to enable even more throughout checks, build permutations of - inline branch expansion - (opt) layer.conf files - (opt) machine.conf files - (opt) distro.conf files - each calculated file group to enable a better coverage. The use permutation is appended to the findings's message automatically. Relates to #607 Signed-off-by: Konrad Weihmann <[email protected]>
Looking good, thanks for your work on this! |
to check on discouraged variables in distro configurations Relates to #607 Signed-off-by: Konrad Weihmann <[email protected]>
to check that only layer.conf specific variables are set in a layer.conf Relates to #607 Signed-off-by: Konrad Weihmann <[email protected]>
to check for discouraged variables in a machine conf Relates to #607 Signed-off-by: Konrad Weihmann <[email protected]>
to enable even more throughout checks, build permutations of - inline branch expansion - (opt) layer.conf files - (opt) machine.conf files - (opt) distro.conf files - each calculated file group to enable a better coverage. The use permutation is appended to the findings's message automatically. Relates to #607 Signed-off-by: Konrad Weihmann <[email protected]>
The current behavior, as far as I can tell, is to accept any number of files on the cmdline, but then it only actually checks the .bb/.bbappend files and the files inherited/included by those (GetRecipes, etc on the Stash). This is not intuitive, in my opinion. Normal behavior for a cmdline tool given a path on the cmdline is to operate on that path, or error out. In the case of a linting tool, I'd expect it to check the specified files.
I specifically want to use rules which check layer.conf files, distros, machines, etc, but that can't be done by the default cli tool. Admittedly, it works just fine to use it in library mode and copy and modify the cli functions to check the other files also, so I've done so, but I feel like the scope of this tool given its README and the name of the command both imply that it's capable of more than just recipes as the entry point, so I'd really like to see this expanded if at all possible. I'm willing to do the work myself and submit a PR if that's preferred and you're open to this enhancement.
Thanks for your time. You've done good work on this. The tool is nice, and while I can't say I agree with the default rules, it's easy enough to adjust that to personal preference.
The text was updated successfully, but these errors were encountered: