-
Notifications
You must be signed in to change notification settings - Fork 57
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
Implement exclusion of rules for the check results #823
Comments
Also related: #310 |
Hello, I hope you it helps. |
Or I'm thinking to make a JSON with a structure to exclude folders/checks. That's a more modern way. |
I'd like to first understand the problem better before jumping into implementation details. Is this something you as the plugins team want to do for every plugin? If a plugin author themself can disable all rules for all files then PCP would become useless... If you do it for all the plugins, how would you manage this information? Store it in the database? Do you want to be able to disable whole checks or individual error/warning codes? Also, if you disable some errors for a file today because of some false positive, then nothing stops the plugin author from introducing more errors in that file in the future. How would you handle that? |
Rules would be reviewed and approved by the reviewer.
We are discussing with the meta team regarding this (no concrete decision is made) but yah possibly in the database.
Exclusion format with excluding error codes with possibility of doing it for whole would be ideal.
Security and other essential rules wont be allowed to be excluded. Only rules which could break the existing plugin will be allowed. Plugin review team will prepare guideline regarding the allowed rules and reviewer will approve based on that. Non-breaking rules would be required to be fixed whether plugin is already published or not. For example: |
This is very vague. There are probably some "essential" rules that were not considered essential in the past, so those would "break" existing plugins too. Without a clear place where we draw the line, I can see this lead to more problems than it solves. Which leads me to: What real problem does this solve? I understand existing plugins will violate certain rules that weren't enforced until now, but why is it a problem to highlight those? Of course, if those were to be enforced, there would need to be a long transition period given during which the developers could update their code. But "hiding" problems just to flag less I find questionable, also for the other reasons @swissspidy shared. From a technical perspective, if you want to start with fewer rules, then why not go with the existing options to only run specific |
There is plan to implement PCP for existing plugins also and if there are ERRORs with Lets say This is not about hiding the error message. It is about scanning plugin in each new release of the plugin enforcing PCP rules without breaking the plugin. |
What about of having a severity for updates? We could ask Meta to use other error severity, for example 6-5 for that. Maybe it could be a good solution. |
Related to #769
In actual this is more advanced form of above issue.
For application of PCP checks to the existing plugin in the directory, we need a mechanism for excluding certain error codes in certain files or directories. This is required because it is not possible to apply all PCP rules to the existing plugins without breaking those.
Few cases:
Example:
Example:
Example:
Example:
A set of rules would be assigned for each plugin which will be reviewed and approved by the reviewer manually.
Issue is here for tracking and gathering ideas and feedbacks regarding the implementation.
Questions:
The text was updated successfully, but these errors were encountered: