-
New Feature
-
Resolution: Duplicate
-
Minor
Hi,
we have a pipeline that is triggering a build and publishes issues with multiple, different JDKs. Currently we're defining different IDs in the publishIssues call with adding a postfix, e.g. for the build with JDK17 we use ID=checkstyle-jdk17 and for the build with JDK21 we use ID=checkstyle-jdk21. In these cases the Icons are not picked up in the overview.
Is it possible to change the behaviour and check for the id prefix to show the correct icon?
Thanks in advance!
Best regards
Norman
- is duplicated by
-
JENKINS-72777 pylint icon does not appear when tool id is not "pylint"
-
- In Progress
-
[JENKINS-73636] Use correct icon when ID is overwritten
Manuel
added a comment - I found a similar issue: When using a custom ID for a tool used by an aggregating recordIssues step, for example
recordIssues(
id: "build-x64-linux",
name: "build (x64-linux)",
aggregatingResults: 'true',
tools: [
[ $class: 'io.jenkins.plugins.analysis.warnings.Cmake', id: 'configure-x64-linux', pattern: 'build-x64-linux.log' ],
[ $class: 'QtTranslation', pattern: 'build-x64-linux.log' ]
]
)
the overview on the build page doesn't use the correct name of the analyzer, and instead displays a generic "Static Analysis", for example
Should I create a dedicated issue for this problem or will this automatically be fixed when this issue is fixed?
Manuel
added a comment - I found a similar issue: When using a custom ID for a tool used by an aggregating recordIssues step, for example
recordIssues(
id: "build-x64-linux",
name: "build (x64-linux)",
aggregatingResults: 'true',
tools: [
[ $class: 'io.jenkins.plugins.analysis.warnings.Cmake', id: 'configure-x64-linux', pattern: 'build-x64-linux.log' ],
[ $class: 'QtTranslation', pattern: 'build-x64-linux.log' ]
]
)
the overview on the build page doesn't use the correct name of the analyzer, and instead displays a generic "Static Analysis", for example
Should I create a dedicated issue for this problem or will this automatically be fixed when this issue is fixed? Hmm, an aggregation always uses the triangle because there is no unique I’d anymore.
Oh sorry, I wasn't clear enough. I'm not talking about the warning triangle, but about the sentence "Static analysis results from: CMake (0), Static Analysis (0), Static Analysis (0)". The two highlighted "Static Analysis" entries are there because I changed the id of the two tools. With the default ID the name of the tool is displayed there instead (just like it is for CMake), which is much more helpful, in particular if I try to aggregate warnings from all parallel build stages which necessarily requires to use custom IDs for basically every tool.
Manuel
added a comment - - edited Oh sorry, I wasn't clear enough. I'm not talking about the warning triangle, but about the sentence "Static analysis results from: CMake (0), Static Analysis (0), Static Analysis (0)". The two highlighted "Static Analysis" entries are there because I changed the id of the two tools. With the default ID the name of the tool is displayed there instead (just like it is for CMake), which is much more helpful, in particular if I try to aggregate warnings from all parallel build stages which necessarily requires to use custom IDs for basically every tool. Yes this is probably the same problem, I am resolving the text and icon by ID. If the ID is changed, then these items cannot be resolved. So no need to create an additional issue.
As mentioned in JENKINS-72777 a new persistent property needs to be added to the results that stores the actual parser ID that has been used.