Alert suppression: allow // codeql[...] suppression comments on the same line#11772
Alert suppression: allow // codeql[...] suppression comments on the same line#11772aibaars wants to merge 2 commits intogithub:mainfrom
// codeql[...] suppression comments on the same line#11772Conversation
66745d5 to
f4a2d99
Compare
f4a2d99 to
54a7702
Compare
Great point. I think this is a (very!) valid concern and my suggestion would be to not allow same-line suppressions for the time being. If that results in significant negative feedback we can reconsider that decision in the future. The opposite would be difficult: once we ship this, it's hard to un-ship it. It's probably worth pointing out that this change does not mean that GitHub code scanning will natively support in-code alert suppression/dismissal (right?). This change opens the door to designing API-based tool automation in the future. If my understanding is correct, then it's probably worth including that note in the description of the PR in order to avoid confusion. Thanks! |
Yes, that's right. The updated suppression queries are meant to be used in combination with https://github.com/advanced-security/dismiss-alerts . I added an introduction to the PR description mentioning the |
|
Thanks for the comments, closing this. |
In an earlier PR I added support for
//codeql[query-id]suppression comments that can be placed on the line before the alert that needs to be suppressed. These suppression comments can be used via https://github.com/advanced-security/dismiss-alerts which automatically suppressed marked alerts via CodeScanning's API.I'm a bit in doubt about whether we should allow
//codeql[query-id]comments on the same line as an alert as well. The main reason for not allowing it, is that it does not play well with the way CodeScanning identifies alerts (content hash of the line containing the alert). As a result the original alert would be marked as "fixed" by CodeScanning, while a fresh duplicate would be created with a suppression marker.On the other hand, users may expect such comments the work on the end of a line even though we'd recommend not doing that for the reason described above.
@sj @AlonaHlobina @turbo