`coverity_prComment_enabled: true` doesn't work?

[mherger]

Hi there

I have an integration with Coverity, which is supposed to report issues in a pull request. For this purpose I have enabled coverity_prComment_enabled: true. Yet, I don't get any PR comments. The workflow basically comes straight out of your documentation:

      - name: Coverity Scan (PR Check)
        if: ${{ github.event_name == 'pull_request' }}
        uses: synopsys-sig/synopsys-action@v1.12.0
        with:
          coverity_url: ${{ env.COVERITY_URL }}
          coverity_user: ${{ env.COVERITY_USER }}
          coverity_passphrase: ${{ secrets.COVERITY_PASSPHRASE }}
          coverity_project_name: ${{ env.COVERITY_PROJECT }}
          coverity_stream_name: ${{ env.COVERITY_STREAM }}
          project_directory: ./lib

          # Policy to break build on
          coverity_policy_view: ${{ env.COVERITY_POLICY }}

          # Enable pull request comments
          coverity_prComment_enabled: true
          github_token: ${{ secrets.GITHUB_TOKEN }} # Required when PR comments is enabled

          include_diagnostics: true

The flag is confirmed in the action's output:

Coverity PR comment is enabled

I added some dead code - which is correctly discovered:

2024-08-29 13:58:23.2970 UTC [Coverity Results] DEBUG: Added entry '1a9d64d0e16091e588eec3af68a20392' to resource 'commenter.issues.[29].uid'
2024-08-29 13:58:23.2970 UTC [Coverity Results] DEBUG: Added entry '### Coverity Issue - Structurally dead code
_Medium CWE-561_
This code cannot be reached: "console.log("this is unreac...".

Actions intended to be performed by the unreachable code will never occur.
' to resource 'commenter.issues.[29].comment'
2024-08-29 13:58:23.2970 UTC [Coverity Results] DEBUG: Added entry 'string' to resource 'commenter.issues.[29].commentType'
2024-08-29 13:58:23.2970 UTC [Coverity Results] DEBUG: Added entry 'sip-helper.js' to resource 'commenter.issues.[29].file'
2024-08-29 13:58:23.2970 UTC [Coverity Results] DEBUG: Added entry 'coverity' to resource 'commenter.issues.[29].from'
2024-08-29 13:58:23.2970 UTC [Coverity Results] DEBUG: Added entry '50' to resource 'commenter.issues.[29].lineNumber'

The analytics data even confirms this was a new finding:

{
    "mergeKey": "1a9d64d0e16091e588eec3af68a20392",
    "strippedMainEventFilePathname": "sip-helper.js",
    "mainEventLineNumber": 50,
    "mainEventColumnNumber": 3,
    "issueTypeDescription": "Structurally dead code",
    "cweCategory": "561",
    "impact": "Medium",
    "mainEventDescription": "This code cannot be reached: \"console.log(\"this is unreac...\".",
    "localEffect": "Actions intended to be performed by the unreachable code will never occur.",
    "presentInReferenceSnapshot": false
}

But then the bridge decides to still not report it, as "not part of PR":

2024-08-29 13:58:26.3839 UTC [GitHub Commenter] DEBUG: The issue from coverity with uid 1a9d64d0e16091e588eec3af68a20392 is not part of PR, skipping to post review comment

What's wrong here?

[lsynopsys]

Do you have any change in the sip-helper.js file? In order to raise an issue, The file should be part of PR. If not, Please share us the diagnostics file by include include_diagnostics: true. @mherger

[mherger]

I'm sorry, I can't share the actual file. But the change is a simple console.log() statement after a return:

  return new SomeClass();

  console.log('this is unreachable code');
  return true;

FWIW: I have a ticket opened on your support system where the issue has been accepted as a bug. Your B.C. has responded:

I have went ahead and set up a bug report. The ticket number is STGCOV-4767. I will let you know when it reaches approved status or if they require further information.

[MarkSmith-eaton]

Hi @mherger, Has there been any updates on this issue? I am working through the same issue. I introduced a change into a file in the PR, the issue was detected and included in the Bridge diagnostics, but the file was not considered as part of the PR despite it clearly being in the PR.

[mherger]

Unfortunately no, no real update. They've asked for more information once I asked for an update. And silence again.

[Yilmazzn]

Can we please get this to work. How come such a simple thing does not work. It is also broken for blackduck scans, but worked in version 0.3.4

[sig-tithi]

Steps to get comments on PR:

1. Run scan on main branch
2. Create a feature branch, raise a PR.
3. Add some additional vulnerable code in the PR branch.
4. if PR comment feature is turned on, comments will be added to the PR

NOTE: Comments on PR gets added only for newly added issues PR branch. If the same was already present in main branch code we will not get comments on PR.

[mherger]

Well, that's how it's supposed to be. This issue discussed here is about the fact that this doesn't work. At least not for us.

[MarkSmith-eaton]

I currently have a support ticket open with Coverity to troubleshoot why my PR commenting doesn't work.

A few things that I've come across that may be helpful to others: 1) Git Branch names with spaces appears to break the plugin resulting in malformed HTTP requests that get rejected. I'll likely end up modifying our build scripts to sanitize the branch names. I'm assuming anything that needs to be escaped in a URL needs to be removed from the branch name. 2) Verify that that the Full scan stream name matches the stream calculated using the base ref in the PR section of the workflow. Any mismatch there will cause a 404 error to be present in the bridge diagnostics log. 3) The workflow yaml itself has permissions that may need to be changed. I tried the following thinking it would help, but it had no effect on my workflow. Maybe others would have better luck trying this (Or some variation).

    permissions:
      pull-requests: write
      contents: read
      discussions: write

I'll update here if I resolve my ticket, so there's at least a searchable solution public.

[mherger]

Would you be using the project_directory configuration to tell Coverity what folder to scan?