Unable to "bind" Additional GitHub repos to new SonarCloud projects [SOLVED]

Relevant configuration info:

  • ALM: GitHub
  • CI: GitHub Actions
  • Analysis Technique: Maven
  • Primary Language: Java
  • Error Message: “Detected project binding: NOT_BOUND”
    (Also, missing GitHub “icon” next to the project’s name in SonarCloud)

I have a SonarCloud account with an organization that is bound to GitHub via the GitHub App.

My GitHib repos use Maven to compile our Java programs.

Last month, I added Sonar’s tasks to the Maven POM.XML file for one of our repositories. I also added the appropriate SONAR_TOKEN secret to GitHub’s secrets and pull that into Maven via an environment variable in GitHub’s maven.yml file. When we tested it, things worked great. I even managed to get Pull Requests going on a dev branch - woot! I was on a roll.

And, in fact, things are still working wonderfully for that first repo.

Today, I tried to convert a second Java/Maven GitHub project over so that it also uses SonarCloud. Basically, I reproduced the POM.xml and maven.yml files from the first repo in this new repo and gave it a whirl. And initially things seemed to work fine when it was just analyzing the master branch. But when I tried to have Sonar review a pull request on a test branch, I got the following error:

[ERROR] Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin: (default-cli) on project commons: Parameter ‘sonar.pullrequest.branch’ is mandatory for a pull request analysis

After checking and re-checking the configurations, I then compared the Maven Logs from the repo that works and the repo that doesn’t and I discovered that the first place they differed was here:

Check ALM binding of project 'commons’
Detected project binding: NOT_BOUND

(In the version that works, the second line has “BOUND” intead of “NOT_BOUND”.)

So, I’m pretty sure that is what is causing the error message I am seeing. I read somewhere that the GitHub App automagically sends across information about branches and pullrequests and I am assuming that is why I didn’t need to set sonar.pullrequest.branch in the first repo.

So, assuming that is the case, I then set about investigating why my second repo wasn’t “bound to GitHub” like my first one is. I validated that my organization is bound to GitHub. I validated that all my POM settings and SONAR_TOKEN secrets where correctly set. I deleted and recreated the second project several times using the steps in the documentation. I even googled until I was googling my previous google results… No luck.

I also noticed that the GitHub icon appears next to my first project’s name on its SonarCloud page however it does NOT appear next to the second project’s name HOWEVER, strangely, on the second project’s SonarCloud page, for “Analysis Method” it says “Analyzed by GitHub Action”.

Does anyone have any hints about what might be wrong with my second repo’s configuration?

All helpful hints/suggestions/guesses/solutions will be GREATLY appreciated!

  • Chip

OK - good news! I found the problem. It turns out there are two ways to create a new project in SonarCloud and THEY ARE DIFFERENT (boo!).

The WRONG way (if you are using GitHub) is to click on the Organization name, then Administration, then Project Manangement, then “Create Project”. That is what I did. Clicking the button will create a new project, but NOT one that is properly associated with the GitHub plugin.

The CORRECT way is to click on the (innocent looking) “+” symbol that is next to your Profile avatar in the upper right corner of the page. You will then see a list of your GitHub repos and can pick one to use for your new Sonar Project and it will be “bound” correctly.

So that’s a :-1: to whoever didn’t duplicate the “+” functionality when using the “Create Project” button on the Project Management page (and also to the skimpy documentation on creating new projects!).

Hello Chip,

Thanks for following up with your own solution to the issue. We will take a look at this functionality and the associated documentation.

1 Like

Hi Chip,

We have taken a look at this issue and agree that it should be fixed.
I have opened SCCOMM-42 to track it.