Project Key Duplicate in Multi Module pom

SonarQube Server / Community Build
1

Must-share information (formatted with Markdown):

  • SonarQube Developer Edition Version 8.6.1 (build 40680)
  • Add SonarQube to our GitLab CI pipeline

I have:

  • successfully installed the db and server.
  • confgiured ALM integration (GitLab API URL, personal access token)
  • added SONAR_HOST_URL and SONAR_TOKEN as env variables in GitLab
  • added Maven Project throgh SonarQube UI
  • copy/pasted sonar.projectKey and sonar.qualitygate.wait in in my parent pom.xml
  • added the following to my .gitlab-ci.yml
sonarqube-check:
  <<: *need_build_artifacts
  stage: test
  #image: maven:3.6.3-jdk-11
  variables:
    SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar"  # Defines the location of the analysis task cache
    GIT_DEPTH: "0"  # Tells git to fetch all the branches of the project, required by the analysis task
    MAVEN_CLI_OPTS: "-DskipTests --settings .gitlab-mvn-settings.xml --batch-mode --errors --show-version"
    MAVEN_REPO_PATH: $CI_PROJECT_DIR/.m2/repository
    FAIL_NEVER: 1
  cache:
    key: "${CI_JOB_NAME}"
    paths:
      - .sonar/cache
  script:
    - docker login <REMOVED>
    - mvn $MAVEN_CLI_OPTS verify sonar:sonar -DskipCompiler=true -Dskip.npm=true
  allow_failure: true

After submitting the pipeline runs but I get the following error:
Caused by: org.sonar.api.utils.MessageException: Project '<PROJECT_KEY>' can't have 2 modules with the following key:

I do see numerous work around solutions, but cannot find anything in the official documentation about best-practice for multi-module maven files with SonarQube.

I’m looking for a quick and easy win to evaluate SonarQube before my 2 week eval period expires.

Should I be setting up each module with it’s own project / key?

Should I be using prefix keys (of which I can find no documentation about?)

1 Like
2

Hi,

Welcome to the community!

You said you’ve

You shouldn’t have to explicitly specify a project key for a Maven project; it should be read automatically from your pom. What happens if you remove that?

 
Ann

3

Your documentation indicates otherwise :slight_smile:

I got around this by adding a module key:
<sonar.moduleKey>${artifactId}</sonar.moduleKey>

So which one is right and why? Alternatively, what are the differences?

Finally, might I suggest updating your documentation? It seems this is a common problem…

5

Hi,

Would you mind pointing me to the docs in question, please?

 
Thx,
Ann

6

From the app:

image
image798Ă—445 31.3 KB

7

Thanks!

9

Hi Ann,

It is still not clear which approach we should be using?

Nothing vs project and module ID?

Thanks!
Colin

10

Hi Colin,

Maven was the first analysis implementation and it follows The Maven Way: convention over configuration. You shouldn’t need to configure anything that can be read/deduced from the project itself. So… nothing. And I’m checking internally that there’s nothing weird about the GitLab environment that would impact that. I really don’t understand how that bit of suggested config got into the tutorial except as an oversight. (But again, double-checking.)

 
Ann

11

Hi,

Sorry for the delay. It turns out that when onboarding a project from the ALM (A.K.A. provisioning the project based on what’s in source control) there’s a chicken & egg situation. If the project were created by first analysis, the Maven scanner would automatically set sonar.projectKey as the project key.

But when the project is created in SonarQube first then the key becomes somewhat arbitrary because it seemed too complicated to say “Go read the group id and artifact id out of your pom file. Join them with a colon and provide that as your project key”.

So instead, the key gets assigned during onboarding & you have to override it with that setting for all subsequent analyses.

And… You do have the ability to Project Settings → Update Key. So you could re-key your project to groupId:artifactId, and drop that setting from your pom (and all the module poms too.)

 
Ann