Support annotations to silence warnings in ebuilds #478
Comments
|
So, ...and: per-package, per-atom (and per-category?) configuration of |
|
Per-atom would be covered if they were within the ebuild itself. I don't know if I see the need to do it per-package or per-category if you can put a small set of statements at the e.g. top of an ebuild to silence relevant warnings. I suspect it would not be worth the effort to implement a new config file for it and standardise it. Example use cases would help if you're really keen on the idea of per-package or per-category. |
|
@thesamesam, but a maintainer turns off warnings in |
|
Again, could you give a more specific use case? You can already disable warnings on the command line if you want. I don't see it as being a very common use case to scan a repo where you have no control over its contents (=> can't fix the issues or add annotations), and then to want to ignore specific warnings but still see them for other packages. I get that it's something one might want to do, but I'm not getting why this is a common or normal thing someone would want to do (and hence worth spending time on). |
|
Well, of this, I think a such control would be much easier to implement. And we will able to reduce/make an "acceptable" version of https://qa-reports.gentoo.org/output/gentoo-ci/output.html (how do people read it?). |
|
I'm just asking why you think it'd be useful. What use case would it enable? You would scan your own packages anyway? There's really not that many one would need to silence. Note that qa-reports.gentoo.org already lets you request per-maintainer output (it's just not advertised very well, try |
Add support for an ebuild to declare a skip annotation for a class of *version* results. This skip annotation must be declared before any non-comment non-empty line (most of the times it would be before the EAPI declaration). Empty lines between the copyright and the annotation are allowed. The annotation line must be precise, only one class per line and every space is required. For example, it would look like: # Copyright 2023 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 # pkgcheck skip: PythonCompatUpdate EAPI=8 Resolves: pkgcore#478 Signed-off-by: Arthur Zamarin <[email protected]>
|
Does gentoo-ci still use the XML reporter format? If it moved to the JSON stream version instead one could use Anyway, I implemented the JsonStream reporter support especially for CI usage. As an example see how the pkgcheck-action github action works and Gentoo's official CI could support the same functionality if it wanted for archived result records. Alternatively it's possible to add deserialization support for some type of XML record format (so |
|
Apparently it does but it's not really relevant, as CI has its own filtering pipeline. |
Add support for an ebuild to declare a skip annotation for a class of *version* results. This skip annotation must be declared before any non-comment non-empty line (most of the times it would be before the EAPI declaration). Empty lines between the copyright and the annotation are allowed. The annotation line must be precise, only one class per line and every space is required. For example, it would look like: # Copyright 2023 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 # pkgcheck skip: PythonCompatUpdate EAPI=8 Resolves: pkgcore#478 Signed-off-by: Arthur Zamarin <[email protected]>
Add support for an ebuild to declare a skip annotation for a class of *version* results. This skip annotation must be declared before any non-comment non-empty line (most of the times it would be before the EAPI declaration). Empty lines between the copyright and the annotation are allowed. The annotation line must be precise, only one class per line and every space is required. For example, it would look like: # Copyright 2023 Gentoo Authors # Distributed under the terms of the GNU General Public License v2 # pkgcheck skip: PythonCompatUpdate EAPI=8 Resolves: pkgcore#478 Signed-off-by: Arthur Zamarin <[email protected]>
I thought we had a bug for this, huh.
We need a way to annotate ebuilds to disable warnings where there's either a policy exemption for something (think e.g. toolchain ebuilds which often do something gnarly), or the warning is a false positive (see #359 for
TarballAvailable, #214 forMissingUnpackerDep).In previous discussions, we've agreed it'd be best to have it be ebuild-wide (so any annotations would affect the whole ebuild) instead of trying to do it per-line (given it's hard to then restrict for all checks, it'd be ugly if you had to place it on a specific line above or so, and it's not worth the complexity).
The text was updated successfully, but these errors were encountered: