Sonarcloud : GitHub Action fails with `Could not find the pullrequest with key`

Newly added repo in Sonarcloud.
Added github action to enable PR support and decoration.
With the PR that is adding the github action, if the pr has been open for a bit or there are a few other prs that go in during that time it eventually fails with Could not find pullrequest with key.
Merging said PR then triggers new develop branch scan successfully.
Token is valid and functioning in other repos.
PR does still exist.

  • ALM used: GitHub
  • CI system used: GitHub Action
    Action:
name: Run SonarCloud Scan - node
on:
    push:
        branches:
            - develop
    pull_request:
        types: [opened, synchronize, reopened]
jobs:
  sonarcloud:
    name: SonarCloud Scan
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3
        with:
          fetch-depth: 0
      - name: Run SonarCloud Scan
        uses: sonarsource/sonarcloud-github-action@master
        env:
          REPO_TOKEN: ${{ secrets.REPO_TOKEN }}
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}

sonar-project.properties

sonar.sources=src
sonar.projectKey=REDACTED
sonar.projectName=REDACTED
sonar.organization=REDACTED
sonar.forceCoverageToZero=true 
  • Scanner command used when applicable
  • Languages of the repository: node
  • Error observed:
INFO: Check ALM binding of project 'REDACTED'
INFO: Detected project binding: BOUND
INFO: Check ALM binding of project 'REDACTED' (done) | time=738ms
INFO: Load project pull requests
INFO: Load project pull requests (done) | time=731ms
INFO: Load branch configuration
INFO: Github event: pull_request
INFO: Auto-configuring pull request 144
INFO: ------------------------------------------------------------------------
INFO: EXECUTION FAILURE
INFO: ------------------------------------------------------------------------
INFO: Total time: 38.367s
INFO: Final Memory: 20M/70M
INFO: ------------------------------------------------------------------------
ERROR: Error during SonarScanner execution
ERROR: Could not find the pullrequest with key '144'
ERROR: Caused by: Error 404 on https://sonarcloud.io/api/alm_integration/show_pullrequest?project=REDACTED&pullrequestKey=144 : {"errors":[{"msg":"The pullrequest could not be found"}]}
ERROR: 
ERROR: Re-run SonarScanner using the -X switch to enable full debug logging.
  • Steps to reproduce
    Project was added to sonarcloud via ui
    Update key
    Disable auto analysis
    Add github action and properties to github repo
    Push PR
    Sonar Scan completes
    Wait a day or so or have a few different other PRs run and merge
    Push new commit or force push
    Error occurs
  • Potential workaround

Do not share screenshots of logs – share the text itself (bonus points for being well-formatted)!

Hey there.

I’m surprised to see this, as the tutorial advises GITHUB_TOKEN – why have you replaced it with REPO_TOKEN?

Sorry, that was an errant copy/paste. Was working on creating an internal gha that calls the sonar action.
It does in fact use the github token.
REPO_TOKEN: ${{ secrets.GITHUB_TOKEN }}

I do have a theory and to be a bit more specific about the pr flow. The PR work to ensure the scans work as expected added branch filtering,

on:
    push:
        branches:
            - develop
            - my_branch
    pull_request:
        types: [opened, synchronize, reopened]
        branches:
           - my_branch

This was done so that we can isolate the pr to only need to be run on this while we work out other actions to generate the code coverage reports. We also didn’t want to potentially fail other prs or create some uneasiness with developers while this was being worked through.

So with these scopes, we would get successful push/synchronize triggered scans, but when we removed the branch scopes to merge it would fail as I had described previously.

So when it scans, the PR hasn’t ever been scanned before in sonar as a PR thus the 404 and it doesn’t exist in sonar. But it gets stuck there, until we merge and then all is well. Is there some check in the PR Auto-configuring that check for the base branch to exist or something? I feel like there may be something there, but I’m unsure how that functions.

I have another repository that is in a similar state now.
They had a successful develop (MAIN) branch scan. 3 weeks later open a new PR, Could not find pullrequest error. The project does show BOUND even though it was scanned via a github action.

Any other thoughts on what may be causing this and what a fix might be?

Hey @Gris13

What does the trigger look like today?

In fact – this error comes from SonarCloud doing a lookup with GitHub and not being able to find the pull request there.

In this case has pull request analysis ever worked? (Earlier, you described a scenario along the lines of:

I’ll also reach out to you for your project key / a failing pull request ID so I can lookup the exact error when SonarCloud queries GitHub.

The triggers appear to be from PR open for this.
The PR existed and I reran the gha to verify, but had the same result.
This was the first PR analysis after adding the gha. So this would have been the first PR scan.

I think the earlier ones, I think it was similar, they didn’t have any previous main branch or pr triggered scan, but just synchronize or push.

Hi @Gris13,

Can I check if you are still experiencing this issue? The issue was raised with me however I had been unavailable and looking now I am not seeing any errors which match the issue you have raised. If you are still experiencing the issue however it would be useful if you have any additional information, such as a recent failure and a date so that I might investigate the issue for you.

Waaaay late in responding here, but we still have these issues on new repositories that are added. So if we generate a new repository and set sonar.properties file and attempt to run the sonarcloud GHA on the initial commit. We will run into this issue. Even if we create a new pr and merge it will fail. We have to manually add the repo in the Admin flow to trigger the auto scan before this error resolves and then we get comparison failures, but those are good after the initial base branch scan.