Support for Standalone *.bbclass File Checks in oelint-adv

[muhammedryavuz]

Standalone Linting Support for .bbclass Files in oelint-adv

Hello,

Hope you’re doing well.

I have noticed that oelint-adv does not seem to support standalone checks for *.bbclass files. When I attempt to run oelint-adv directly on a .bbclass file, I do not receive any output, errors, or failures. However, I would like oelint-adv to provide feedback on *.bbclass files in my repository.

Interestingly, when I run oelint-adv on a recipe (.bb file) that inherits a .bbclass, the linter does check the inherited .bbclass files.

I’m unsure if this is the intended behavior, but my use case requires running oelint-adv directly on .bbclass files without needing a corresponding recipe.

I have also checked the following threads and discussions:

• Issue #729
• Related comment
• Discussion #598

However, my use case is not about suppressing files but rather ensuring that oelint-adv can report issues when invalid changes are introduced in a .bbclass file.

Questions:

1. Is oelint-adv supposed to support standalone linting of .bbclass files?
2. If not, would it be possible to add support for this feature?
3. Are there any workarounds to check .bbclass files independently?

Thanks in advance for any insights!

[priv-kweihmann]

Indeed standalone checks of bbclass files are currently not supported.

But it should be doable to change that (just requires a few patches here and there).

[muhammedryavuz]

Do you think it is feasible? We can do that, if it's possible. Btw, I am not sure if you forgot the links on there 😄.

[muhammedryavuz]

Hi @priv-kweihmann,

Thanks again for your response!
I see that standalone .bbclass files may need filtering to exclude certain checks (e.g., suggested variable rules) as mentioned in issue #732. However, I’d like to clarify:

• Will the excluded checks for standalone .bbclass files still apply when the .bbclass is inherited by a recipe?
• In other words, if some rules are skipped for standalone .bbclass files, will they be enforced when the .bbclass is used in a recipe?

I’d appreciate any insights on how rule validation differs in these cases. Thanks!

[priv-kweihmann]

Started working on the implementation at #733.

And to answer your question, yes the implementation will cover both cases.
Depending on the file passed into the parser, different sets of rules will be run.
So if it's a recipe then the automatically added bbclass will be checked with the rule set of the recipe.
If just a bbclass is passed a different (likely smaller) rule set applies.

[muhammedryavuz]

Thank you for the quick response and for implementing this so swiftly - @priv-kweihmann !

I've been reviewing the implementation in more detail, and I’ve already validated it locally against my case — it’s working as expected. From what I see, with this change, we can now create custom rules, assign the appropriate classification, and target them specifically at .bbclass files.

That said, I wanted to clarify one point regarding filtering and classification:

Is there (or will there be) a way to filter or scope existing rules by file type — for example, apply a different severity depending on whether the rule is triggered in a .bbclass or a .bb recipe?

For instance, suppose there’s a default rule like oelint_adv/rule_base/rule_var_bbvars.py that currently applies as a warning to both .bb and .bbclass files — would it be possible to override this severity differently per file type, e.g.:

• As a warning when used in a .bb recipe
• But as an error when triggered in a .bbclass file

I understand rulefile.json lets us change severities, but I’m not sure if it supports conditional filtering based on the file classification without modifying the rule itself. Based on the documentation (Defining a ruleset - which we also use), this doesn’t seem to be covered.

For reference, I currently observe the following rules executing under multiple classifications on #733 :

Rule File	Classification ID	Severity	Applies To
rule_bbclass_exportfunctions.py	oelint.exportfunction.dash	error	.bbclass only
rule_bbclass_underscores.py	oelint.bbclass.underscores	error	.bbclass only
rule_var_bbvars.py	oelint.vars.bbvars	warning	.bb, .bbclass, .bbappend
rule_var_addpylib.py	oelint.var.addpylib	error	.bbclass, .bbappend, .bb
rule_var_filesextrapaths.py	oelint.vars.fileextrapaths	warning	.bbclass, distroconf, layerconf, machineconf, .bb
rule_var_spec.py	oelint.vars.specific	error	.bbclass

Would love to hear your thoughts on whether conditional rule filtering by file type is feasible — either now or in future versions. Thanks again for your support!

[priv-kweihmann]

Conditional filtering overdoes it in my opinion.
The proposed classification should already provide a best effort to reduce false positives as much as possible.

And rulefile is an option to control which rules are loaded by the linter at all - plus a potential tweaking of the severity.

That said, I think, squeezing in file classifications in that construction (rulefile), will be almost unmaintainable,
hard to read/review and I'm concerned that it will be mainly abused to hide findings
(resulting from the classification) that should be better fixed than ignored.

What I could potentially see, is that there could be a new field in the output format, telling the interested user which original file was passed into the linter (causing the additional files to be picked up along the way), so a secondary filter using the libmode feature (see #598), could take over that part, for the (IMO small) group of users that need that.

Nevertheless, conditional rule filtering as a mainline feature, is nothing I see, support nor will actively work on

[muhammedryavuz]

Thank you for the thoughtful and clear clarification @priv-kweihmann! I completely understand your stance on conditional filtering and agree that keeping the system maintainable and simple is important. Your explanation helps me align expectations, and I appreciate the insight.

I look forward to the upcoming release, and once it's available, I'll be happy to close the thread. Should I archive the thread myself, or will you take care of that once the release is out?

Thanks again for your continued support!