[JENKINS-58716] Replace AbstractMultiParentHook.getParentUrl with a processed pomData.connectionUrl

[jglick]

Follows up #181 for multimodule repos. For example, jenkinsci/blueocean-plugin#2094 was deployed with

  <scm>
    <connection>scm:git:https://github.com/dwnusbaum/blueocean-plugin.git/blueocean-bitbucket-pipeline</connection>
    <developerConnection>scm:git:https://github.com/dwnusbaum/blueocean-plugin.git/blueocean-bitbucket-pipeline</developerConnection>
    <tag>e72b727f00ca3d0dd9325e4b9c46369b890af52d</tag>
    <url>https://github.com/dwnusbaum/blueocean-plugin/blueocean-bitbucket-pipeline</url>
  </scm>

We need to check out dwnusbaum/blueocean-plugin@e72b727 as a result.

[basil]

The part of this change that removes AbstractMultiParentHook#getParentUrl() looks great to me. In fact, I had considered making such a change a long time ago.

The part of this change that I have a question about is the part that trims the subdirectories. This certainly works, but I am left wondering why /project/scm/connection was set to scm:git:https://github.com/dwnusbaum/blueocean-plugin.git/blueocean-bitbucket-pipeline in the first place. It seems to me that this may not actually be a valid value for /project/scm/connection. The documentation for the Maven Git SCM implementation shows that this value is intended to be a remote URL for a Git repository by using the term path_to_repository. dwnusbaum/blueocean-plugin.git/blueocean-bitbucket-pipeline is clearly not a path to a Git repository, but dwnusbaum/blueocean-plugin.git is.

I believe the word @jglick prefers to use to describe such code is "trick." I am wondering whether we have at least considered the alternative: fixing up /project/scm/connection to contain a valid value. Not only would this more closely adhere to the spirit of the Maven Git SCM implementation, but also we would not have to trim the subdirectories, aligning the regular expression in AbstractMultiParentHook#action with the one in PluginCompatTester#cloneFromSCM. Feel free to let me know if I am missing something obvious or if there is something prohibitively difficult about doing this.

[jglick]

The automatic appending of submodule paths to /project/scm/connection is baked into Maven and hard to get rid of. I think it dates to Subversion days, when https://svn.mycorp/trunk/some/sub/module/ was in fact a legal thing to check out. It does not work at all for Git, so we have to work around that in PCT. If you find a way to fix this at the supply side using some POM directive or whatever, let me know.

[jglick]

I mean, you can redundantly specify <scm> in each child module’s pom.xml to avoid the inheritance, but I would like to avoid that.

[basil]

The automatic appending of submodule paths to /project/scm/connection is baked into Maven and hard to get rid of. I think it dates to Subversion days, when https://svn.mycorp/trunk/some/sub/module/ was in fact a legal thing to check out. It does not work at all for Git, so we have to work around that in PCT.

I see. This is beyond our control in the Jenkins project, so a workaround seems appropriate.

I mean, you can redundantly specify <scm> in each child module’s pom.xml to avoid the inheritance, but I would like to avoid that.

Agreed.

[raul-arabaolaza]

Code looks good to me, I am going to perform some tests on full runs using custom war files and local sources to be sure and if nothing happens we are good to go from my side

[raul-arabaolaza]

I have not found any regression (finally) generated by this change in proprietary wars, and also the PR failure is caused by an infra issue, merging