Uploaded image for project: 'SonarQube'
  1. SonarQube
  2. SONAR-11853

Auto-configuration pull requests on Jenkins

    XMLWordPrintable

    Details

    • Type: New Feature
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 8.3
    • Component/s: Branch & PR, Scanner
    • Labels:
    • Edition:
      Developer
    • Production Notes:
      None

      Description

      Branch analysis in Jenkins

      The Bitbucket, GitHub and Gitlab Branch Source Plugins are a popular way to trigger project analysis from Jenkins.

      Jenkins will set up the job and perform SCM checkout based on values exposed by those plugins through an API.

      It also sets environment variables that we could use to make configuration of SonarQube analysis simpler.

      Detect Jenkins

      First, to detect that the scanner is running on Jenkins, we could verify that JENKINS_URL and JENKINS_HOME are set.

      Detect PRs

      On a PR, CHANGE_TARGET is set and can be used to detect that what is being built is a P/R.

      The scanner can be configured in the following way.

      • sonar.pullrequest.base: use CHANGE_TARGET
      • sonar.pullrequest.branch: use CHANGE_BRANCH
      • sonar.pullrequest.key: use CHANGE_ID

      For sonar.scm.revision it's a little bit trickier because unfortunately there is no environment variable exposed that will always contain the correct value.
      CHANGE_ID contains the commit ID being built but it's not necessarily the HEAD of the branch from where the P/R originates from.
      The default checkout strategy used by Jenkins is to merge the target branch onto the P/R branch. If both branches have diverged, this will create a merge commit that only exists locally. In that case, that's the commit in CHANGE_ID and it will be useless for P/R decoration since it doesn't even exist in the ALM.

      To find the HEAD of the branch from where the pull request was created, we can try to use git to read the local references. Jenkins fetches the pull request branch to refs/remotes/origin/[PR ID] in both checkout strategies. "PR ID" will be something like "PR-7", and it can be detected using the environment variables BRANCH_NAME or GIT_BRANCH.

      This strategy was tested with GitLab branch plugin and GitHub branch plugin.
       

      Instead of:

              stage('SonarQube branch analysis') {
                  agent any
                  when {
                      not {
                          changeRequest()
                      }
                  }
                  steps {
                      withSonarQubeEnv(installationName: 'SonarQube') {
                          sh "mvn verify org.sonarsource.scanner.maven:sonar-maven-plugin:RELEASE:sonar -Pcoverage \
                              -Dsonar.projectKey=jenkins-demo-sonarsource_jenkins-demo \
                              -Dsonar.branch.name=${env.BRANCH_NAME}"
                      }
                  }
              }
      
              stage('SonarQube PR analysis') {
                  agent any
                  when {
                      changeRequest()
                  }
                  steps {
                      withSonarQubeEnv(installationName: 'SonarQube') {
                          sh "mvn verify org.sonarsource.scanner.maven:sonar-maven-plugin:RELEASE:sonar -Pcoverage \
                              -Dsonar.projectKey=jenkins-demo-sonarsource_jenkins-demo \
                              -Dsonar.pullrequest.key=${env.CHANGE_ID} \
                              -Dsonar.pullrequest.base=${env.CHANGE_TARGET} \
                              -Dsonar.pullrequest.branch=${env.CHANGE_BRANCH}"
                      }
                  }
              }
      

      we would like:

              stage('SonarQube analysis') {
                  agent any
                  steps {
                      withSonarQubeEnv(installationName: 'SonarQube') {
                          sh "mvn verify org.sonarsource.scanner.maven:sonar-maven-plugin:RELEASE:sonar -Pcoverage \
                              -Dsonar.projectKey=jenkins-demo-sonarsource_jenkins-demo
                      }
                  }
              }
      

      Overriding parameters

      If any of the 4 parameters is manually specified by the user, the automatic detection is disabled for all 4 parameters.

      Implementation

      Implementation can be done in the scanner-engine (or in one of its extensions).
      It will require a new dependency on JGit, to avoid having to use the Git SCM plugin for it.

      Nice to have

      Log a info/warn if user is configuring branch/PR analysis and we know we can do it automatically.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              duarte.meneses Duarte Meneses
              Reporter:
              julien.henry Julien Henry
              Votes:
              1 Vote for this issue
              Watchers:
              9 Start watching this issue

                Dates

                Due:
                Created:
                Updated:
                Resolved: