Azure DevOps Services SonarQube server [https://domain.ltd] can not be reached (anymore)

SonarQube Server / Community Build
,
1

Hi everyone,
we are suddenly have the issue that our SonarQube Server Community Edition is not reachable anymore by Azure DevOps Pipelines. It used to work without any issue, till we recently updated to Sonarqube 8.3.1.34397 (we don’t know from which version, since we just pulled the newest Docker image but it was 8.x). SonarQube runs within a docker instance routed by Traefik 2.2 and is accessible via web. The SonarQube server is also accessible even within the pipeline tested with curl https://domain.ltd/batch/index. Here is the failed task log:sonarqube.log (3.5 KB)

Also there are no further firewall restrictions set. All inbound traffic is allowd on 80+443 (SonarQube-traffic is routed to internal docker port 9000 of the SonarQube instance)

We didn’t know how to set -X switch via Azure DevOps YAML, so we set the environment variable SONAR_SCANNER_OPTS=-Djavax.net.debug=all to get further information.

Anyone an idea what might cause this issue? thanks in advance!

2

Our pipeline SonarQube tasks (yml) looks like this:

- task: SonarQubePrepare@4
  inputs:
    SonarQube: 'Sonarqube'
    scannerMode: 'CLI'
    configMode: 'manual'
    cliProjectKey: 'Project.Backend'
    cliProjectName: 'Project.Backend'
    cliSources: '.'
    extraProperties: |
      # Additional properties that will be passed to the scanner, 
      # Put one key=value per line, example:
      # sonar.exclusions=**/*.bin
      sonar.verbose=true

- task: SonarQubeAnalyze@4

- task: SonarQubePublish@4
  inputs:
    pollingTimeoutSec: '300'
3

does anyone has an idea what might cause this issue or had similar issues? thanks for any hints!

5

Hi @sitch

Sorry for the late reply.

Could you please send again this log with the pipeline variable “system.debug=true” please ? So then i’ll have access to the full stack of the error.

Thanks in advance.
Mickaël

6

Hi Mickaël
no problem, thanks for your response. It seems like the issue has been resolved. I guess it was maybe a problem related to a bug in an edge routing service we use.

thanks anyway!

1 Like
7

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.