Sonar Scan - Azure Pipeline and bean Exception

I have a pipeline, trying to scan android java project.
Sonar Server is CE
Scanner task in pipeline is
Version : 5.15.0

Pipeline code


Command gets translated as
D:\DAgent_work\4\s\gradlew.bat build sonarqube"

Warning flashed as

Task :sonarqube
Task ‘sonarqube’ is deprecated. Use ‘sonar’ instead.

and exception gets as

* What went wrong:
Execution failed for task ':sonarqube'.
> Error creating bean with name '': Unsatisfied dependency expressed through constructor parameter 7; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name '': Unsatisfied dependency expressed through constructor parameter 0; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'ActiveRules' defined in org.sonar.scanner.rule.ActiveRulesProvider: Bean instantiation via factory method failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.sonar.api.batch.rule.internal.DefaultActiveRules]: Factory method 'provide' threw exception; nested exception is java.lang.IllegalStateException: 

Fail to request url:,name,severity,lang,internalKey,templateKey,params,actives,createdAt,updatedAt,deprecatedKeys&activation=true&qprofile=AYhEtkJ-KbPFOk-Fv97_&ps=500&p=1

Observation is -
Url is available and does respond to rules. Azure Agent and sonar is on same server.

Can any one guess what could be error ?

But on same machine via command prompt If I fire

D:\DAgent_work\4\s>.\gradlew sonar

It works well.


Based on the error message, analysis can’t talk to your SonarQube server from the build agent. You should probably talk to your network folks.


There is no network - both are on same machine. I checked configuration IP address url which is used in configuration is reachable.

Interestingly when I fire command local … It works.

D:\DAgent_work\4\s>.\gradlew sonarqube

54 actionable tasks: 9 executed, 45 up-to-date
Configuration cache entry discarded because incompatible task was found: ‘:sonarqube’.


If analysis is running on the same machine as the SonarQube server - which we really don’t recommend - then I don’t understand your distinction between the analysis that fails and

Nonetheless, the root problem here is

Since it seems that you’ve already independently verified that SonarQube is running, the problem lies outside of analysis itself. You’re going to have to figure out why that request fails.