javamachr / sonar-gitlab-plugin

Add to each commit GitLab in a global commentary on the new anomalies added by this commit and add comment lines of modified files
GNU Lesser General Public License v3.0
121 stars 21 forks source link

External job for branch analysis does not report issues when it's added to a merge request pipeline #29

Open Kevinbarre opened 1 year ago

Kevinbarre commented 1 year ago

Hello,

I encoutered an issue similar to what's described in this ticket: https://github.com/gabrie-allaigre/sonar-gitlab-plugin/issues/211

So I tried the solution from this comment https://github.com/gabrie-allaigre/sonar-gitlab-plugin/issues/211#issuecomment-530736404 , which is to use -Dsonar.gitlab.ref_name=${CI_MERGE_REQUEST_REF_PATH} instead of -Dsonar.gitlab.ref_name="${CI_COMMIT_REF_NAME}".

This solves the initial issue, and the external job is now correctly displayed in the merge request pipeline. But in this case, the global comment does not display the issues, but always the message "SonarQube analysis reported no issues.". It still detects that the quality gate is failed, so that's unclear to me why this happens. Also when I go into SonarQube, I can see the issues listed for this branch analysis.

Maybe I'm not using the configuration correctly, here's what I have so far:

    mvn
    clean test
    sonar:sonar
    -Dsonar.login=${SONAR_TOKEN}
    -Dsonar.branch.name=${CI_COMMIT_REF_NAME}
    -Dsonar.gitlab.api_version=v4
    -Dsonar.gitlab.project_id=${CI_PROJECT_ID}
    -Dsonar.gitlab.commit_sha=${CI_COMMIT_SHA}
    -Dsonar.gitlab.ref_name=${CI_MERGE_REQUEST_REF_PATH}
    -Dsonar.gitlab.user_token=${TECHNICAL_USER_GITLAB_TOKEN}
    -Dsonar.gitlab.ci_merge_request_iid=${CI_MERGE_REQUEST_IID}
    -Dsonar.gitlab.merge_request_discussion=true

(I initialy didn't use the -Dsonar.gitlab.ci_merge_request_iid=${CI_MERGE_REQUEST_IID} and -Dsonar.gitlab.merge_request_discussion=true, and I saw no difference when adding them, so I'm probably misusing them as well.)

After trying to read through the plugin source code, my guess is that it's because the ref_name parameter is used at two different places:

  1. In https://github.com/javamachr/sonar-gitlab-plugin/blob/master/src/main/java/com/talanlabs/sonar/plugins/gitlab/SonarFacade.java#L222 , where it's used to retrieve issues from Sonar. So when its value is ${CI_BUILD_REF_NAME}, it works, and when its value is ${CI_MERGE_REQUEST_REF_PATH} it doesn't.
  2. In https://github.com/javamachr/sonar-gitlab-plugin/blob/master/src/main/java/com/talanlabs/sonar/plugins/gitlab/GitLabApiV4Wrapper.java#L223 , where it's used to post the comment to Gitlab. So when its values is ${CI_BUILD_REF_NAME}, it has no link to the MR and creates a new pipeline for the branch, and when its value is ${CI_MERGE_REQUEST_REF_PATH} it correctly posts the comment into the existing merge request pipeline.

Maybe it would be possible to add an additional parameter -Dsonar.gitlab.ci_merge_request_ref_path, so that we can provide both -Dsonar.gitlab.ref_name=${CI_COMMIT_REF_NAME}, for issues retrieval, and -Dsonar.gitlab.ci_merge_request_ref_path=${CI_MERGE_REQUEST_REF_PATH} so the external job is correctly part of the merge request pipeline ?