-
Bug
-
Resolution: Not A Defect
-
Minor
-
Jenkins: 2.68
Git-Plugin: 3.41
If a Git SCM checkout is configured with multiple repositories then all change sets for the build will use GitHubProjectProperty value for URL when building change links.
Pipeline Example:
pipeline { agent any stages { stage('Checkout'){ steps { checkout( [ $class: 'GitSCM', branches: [[name: '*/master']], doGenerateSubmoduleConfigurations: false, extensions: [], submoduleCfg: [], userRemoteConfigs: [ [credentialsId: 'githubId', url: 'https://github.com/Organization/repo-one'], [credentialsId: 'githubId', url: 'https://github.com/Organization/repo-two'] ] ] ) } } } }
If I were to trigger a build by pushing a change to 'https://github.com/Organization/repo-two' then the change set links would be 'https://github.com/Organization/repo-one/commit/<CommitId>' resulting in a 404.
To clarify this still happens even if the repositories are broken into seperate SCM checkouts in a single pipeline. Issue is slightly mitigated by declaring the repository browser type on the individual checkouts.
This also occurs on non pipeline jobs as well.
I think you need to use two "checkout" commands in your pipeline, rather than a single checkout with two userRemoteConfigs. The git plugin (for legacy reasons) considers two repositories in the same checkout to be equivalent of one another.
You likely also want to use the pipeline dir('xx') block to perform each checkout into an independent subdirectory, otherwise there is a risk that the the contents of the two repositories will be "co-mingled" destructively in the root of the workspace directory.
I think you've described a real bug, even with those two observations, but it would be best if you could correct the bug description and confirm that it still has the behavior you describe.