Hi @pmatos Can you provide more details on this scenario? I'm not sure I get what you're hoping to accomplish. Thanks!

Hi @pmatos Can you provide more details on this scenario? I'm not sure I get what you're hoping to accomplish. Thanks!

Sure - apologies if I was too terse.

I am discussing racket/racket here. In our CI, we can build from the same sources 3 different types of compiler: let's call it a, b and c. Each of these, due to the way they are compiled (mainly compile-time parameters) can have different static analysis results.

We run the LLVM static analyzer scan-build on the three different compilation modes, create sarif files and upload. The problem is that github aggregates the results based on tool name. The tool name is clang for all of the three modes. However, it would be good to tag the results as well. So we can tag the results during the sarif upload and call them vulnerabilities-a, vulnerabilities-b and vulnerabilities-c for each of the compilation modes.

Also, I recall that this is relevant not only for different compilation modes but also different architectures. So, in arm32 you might get one set of vulnerabilities and in arm64 another set. The same tool clang will create both sarif files but it would be great to distinguish which of the architecture contain some vulnerability. If you nowadays just use upload-sarif for both arm32 and arm64 vulnerabilities they will be conflated in the vulnerabilities panel under the clang tool.

I have added a workaround - which hope it works - to trick the system into splitting the vulnerabilities. Instead of splitting by tag (which is what makes sense) I split by toolname. That's what racket/racket@e62b3b8 is about.

@pmatos Thanks for clarifying (and sorry for the delay). It sounds like this is the same pattern we're using the matrix parameter for. That would allow you to separate the vulnerabilities according to a particular configuration without changing the tool name.

Sorry - I know this is an old convo :) but the closest thing to what seems like a general case - "one tool, many artifacts" - sarif problem :) Is using matrix still the best "workaround" here?

@turbo or @AlonaHlobina could you have a look at this?

It sounds like what you want is to you want is to specify a custom category for each configuration.

This will allow you to run multiple analyses over the same code when it is built for different platforms and using different configurations.