SVN SCM Provider 1.3 : Support of "parent" working copy ?

[Alix Lourme]

Hi,

After a recent SonarQube LTS upgrade (v4 -> 5.6.4), some Subversion projects analysis (with Maven) fail with :

SCM provider was set to "local" but no SCM provider found for this key. Supported SCM providers are svn,git

After analysis it occurs when the Subversion checkout directory is parent of the root Maven project, like:

• checkout http://svn.company.com/repoX/trunk/, containing
• my-app-root
• my-app-module
• Execute Maven command on my-app-root

If the working copy is the same as Maven working directory, it works perfectly, like:

• checkout http://svn.company.com/repoX/trunk/my-app-root
• checkout http://svn.company.com/repoX/trunk/my-app-module
• Execute Maven command on my-app-root

The first configuration could be convenient when project contains many module (and worked fine in SonarQube v4 LTS). I try with sonar-maven-plugin 2.6->3.2 but no change.

=> This is a wanted behavior (seems logic with SvnScmProvider.java implementation), or the use case was lost with the plugin improvment (I didn't see that in changelog), or could be considered like a bug ?

Thanks in advance.
Best regards

NB: I hesitate to post this subject on stackoverflow, but this is perhaps more about plugin history.

[Alix Lourme]

Hi,

FI, this problem seems occur when Maven pom contains:

<scm>
    <connection>scm:local:none</connection>
    <developerConnection>scm:local:none</developerConnection>
</scm>

=> When .svn/ directory is not present in the project directory but in a top-parent, this property is used ...

Best regards.

[Julien HENRY]

Hi Alix,

In fact autodetection is only used as a fallback when scm is not provided by the user. So in your example, having scm connection defined to "local" in your pom will always make it fail.

If you remove the scm entry from your pom, then autodetection will be used. And you're right that for the SVN provider it is currently very limited since it will only work when project root = SVN working directory root. We should probably implement something similar to what we did for Git (https://jira.sonarsource.com/browse/SONARSCGIT-9).

Ticket created:

https://jira.sonarsource.com/browse/SONARSCSVN-11

++

Julien

[Alix Lourme]

Hi Julien,

Thanks for the reply, and happy new year :-)

In fact autodetection is only used as a fallback when scm is not provided by the user. So in your example, having scm connection defined to "local" in your pom will always make it fail.

I'm sorry, but I'm not agree with that. The scm configuration seems used when autodetection is failed.

This scenario is a proof (usable with any SVN project):

[download & run SonarQube LTS, contains SVN v1.3 plugin]

svn co http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-project-info-reports-plugin
cd maven-project-info-reports-plugin
[vi_or_edit pom.xml, replace scm.[connection&developerConnection] by scm:local:none ]
mvn package -Dmaven.test.skip=true
mvn sonar:sonar -Dsonar.host.url=http://localhost:9000

The result is OK:

[INFO] Sensor SCM Sensor
[INFO] SCM provider for this project is: svn
[INFO] 63 files to be analyzed
[INFO] 4/63 files analyzed
...
[INFO] 63/63 files analyzed
[INFO] Sensor SCM Sensor (done) | time=90496ms

IMO, this behavior should not change:

• A working copy information (if can be retrieved) is better than a user configuration.
• When multi-branch SonarQube process are configured in CI platform, the pom content on SCM is often bad.

Ticket created: https://jira.sonarsource.com/browse/SONARSCSVN-11

Thank you :-). I didn't understand why it has worked with previous v4 LTS, but this is not very important.

Best regards.

[Julien HENRY]

Le mardi 3 janvier 2017 17:45:06 UTC+1, Alix Lourme a écrit :

Hi Julien,

Thanks for the reply, and happy new year :-)

Happy new year to you! :)

 

In fact autodetection is only used as a fallback when scm is not provided by the user. So in your example, having scm connection defined to "local" in your pom will always make it fail.

I'm sorry, but I'm not agree with that. The scm configuration seems used when autodetection is failed.

You're right, in fact the order is:

  1) consider sonar.scm.provider if set

  2) autodetection

  3) consider sonar.links.scm_dev (that correspond to Maven developerConnection)

 

IMO, this behavior should not change:

• A working copy information (if can be retrieved) is better than a user configuration.
• When multi-branch SonarQube process are configured in CI platform, the pom content on SCM is often bad.

I agree :)

 

Ticket created: https://jira.sonarsource.com/browse/SONARSCSVN-11

Thank you :-). I didn't understand why it has worked with previous v4 LTS, but this is not very important.

At that time we were relying on Maven SCM framework and behavior was totally different.

[Alix Lourme]

At that time we were relying on Maven SCM framework and behavior was totally different.

Thanks for the precision.