VSTS Prepare Analysis ignores .proxybypass list

  • versions used (SonarQube, Scanner, Plugin, and any relevant extension)
    VSTS agents:
    Linux: 2.139.1
    SonarQube VSTS plugin: 4.3.2

  • error observed

  • steps to reproduce

We have set up the VSTS agent in our internal network to work with a proxy to be able to connect to the visualstudio.com instance. We also defined a .proxybapass file in the root of the VSTS agent directory to ignore this proxy for certain addresses. The rules in this file are disregarded for the node.js task though apparently. I pasted an excerpt from the VSTS debug logs beneath. As you can see we’re still bouncing at the proxy server.
To rule out that node.js is the culprit I used the same call that the SonarQube plugin uses in a small JS program which I ran through a standalone node.js instance and this one worked like a charme. Side note: I had to set the environment variable NO_PROXY for this to work correctly or else I bounced at the proxy too. When running SonarQube plugin in the VSTS Agent context though this environment variable (NO_PROXY) is not used as the agent is exposing its own variables to access proxies.

The issue was first discussed on the VSTS issue tracker: https://github.com/Microsoft/vsts-agent/issues/1800

Excerpt from debug run:

2018-08-31T12:32:12.7388666Z ##[debug]Agent.ProxyUrl=[ProxyURL:Port] 2018-08-31T12:32:12.7389207Z ##[debug]Agent.ProxyUsername=undefined 2018-08-31T12:32:12.7389618Z ##[debug]Agent.ProxyPassword=undefined 2018-08-31T12:32:12.7390019Z ##[debug]Agent.ProxyBypassList=["my.url"] 2018-08-31T12:32:12.7390440Z ##[debug]expose agent proxy configuration. 2018-08-31T12:32:12.7390843Z ##[debug]Agent.CAInfo=undefined 2018-08-31T12:32:12.7391232Z ##[debug]Agent.ClientCert=undefined 2018-08-31T12:32:12.7391640Z ##[debug]Agent.SkipCertValidation=undefined 2018-08-31T12:32:12.7392209Z ##[debug]SonarQube=a874a7fc-6e35-4660-bd3d-c97ca7d9d871 2018-08-31T12:32:12.7392858Z ##[debug]a874a7fc-6e35-4660-bd3d-c97ca7d9d871=https://sonar.internal/sonar 2018-08-31T12:32:12.7393307Z ##[debug]a874a7fc-6e35-4660-bd3d-c97ca7d9d871 auth param apitoken = null 2018-08-31T12:32:12.7393956Z ##[debug]a874a7fc-6e35-4660-bd3d-c97ca7d9d871 auth param username = ******** 2018-08-31T12:32:12.7394448Z ##[debug]a874a7fc-6e35-4660-bd3d-c97ca7d9d871 auth param password = null 2018-08-31T12:32:12.7394870Z ##[debug]organization=null 2018-08-31T12:32:12.7395247Z ##[debug]scannerMode=MSBuild 2018-08-31T12:32:12.7395662Z ##[debug]projectKey=Com.Organization.ProjectName 2018-08-31T12:32:12.7396077Z ##[debug]projectName=ProjectName 2018-08-31T12:32:12.7396478Z ##[debug]projectVersion=1.0 2018-08-31T12:32:12.7396988Z ##[debug][SQ] API GET: '/api/server/version' with query "undefined" 2018-08-31T12:32:12.7398359Z ##[debug]Response: 403 Body: "<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

  • potential workaround
1 Like

Hi, has this been solved in the mean while? We are experiencing same sort of issues with our private Azure DevOps agents and using the SonarCloud tasks. The SonarCloud task cannot reach sonarcloud.io. Our agents have proxy settings, and we even tried https.proxy / http.proxy settings as additional parameters. Nothing worked, as our network people told me that the SonarCloud task still wants to go out directly to sonarcloud.io instead of via the proxy. Our firewall does not allow direct traffic.
Please fix this, e.g. by using the proxy as defined on the agent itself, as security is important.

PS: Using SonarCloud task v1.70

As you can see no one even bothered to answer let alone that they opened a bug ticket (at least I didn’t see it monitoring the JIRA for some time after posting this). I guess this error didn’t get enough user attention to be worth resolving it.

1 Like

@Colin @ganncamp or maybe someone else from SonarSource that can assist in this issue? I work for a financial institution and proxy traffic is very important and currently it seems the Azure DevOps (VSTS) tasks from SonarSource are not using the existing proxy settings. This hampers us from making full use of SonarQube

1 Like