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.

          [JENKINS-45815] Wrong ChangeSet Url for N+1 Repositories.

          Mark Waite added a comment -

          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.

          Mark Waite added a comment - 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.

          Trevor Howard added a comment -

          Can confirm two individual SCM checkouts in a Pipeline script still runs into this problem.

          If SCM browser is explicitly set to GitHubWeb the generated 'gitHubWeb' link for a change does resolve correctly. However the corresponding 'commit: <commitId>' to the left of the 'gitHubWeb' link is still broken.

          Also this problem can be duplicated on non pipeline Jobs as well.

          Not too concerned about these checkouts clobbering each other in a shared workspace. Ran into this potential bug while building a plugin that generates change management reports based off contents of GitSCM and GitChangeSetList objects.

           

          Trevor Howard added a comment - Can confirm two individual SCM checkouts in a Pipeline script still runs into this problem. If SCM browser is explicitly set to GitHubWeb the generated 'gitHubWeb' link for a change does resolve correctly. However the corresponding 'commit: <commitId>' to the left of the 'gitHubWeb' link is still broken. Also this problem can be duplicated on non pipeline Jobs as well. Not too concerned about these checkouts clobbering each other in a shared workspace. Ran into this potential bug while building a plugin that generates change management reports based off contents of GitSCM and GitChangeSetList objects.  

          Mark Waite added a comment -

          Thanks for confirming. I'm not sure that you'll get the results you want when specifying two userRemoteConfig values in a single checkout command. I'm not aware of any tests in the git plugin which check the behavior of multiple userRemoteConfig values with disjoint repositories.

          Mark Waite added a comment - Thanks for confirming. I'm not sure that you'll get the results you want when specifying two userRemoteConfig values in a single checkout command. I'm not aware of any tests in the git plugin which check the behavior of multiple userRemoteConfig values with disjoint repositories.

          Trevor Howard added a comment - - edited

          So the bad links were being generated by having a value assigned to GitHubProjectProperty in the job.

          It'd be nice to know which SCM/UserRemoteConfig instance a ChangeLogSet is generated from. If a browser is not set then generating accurate reports is very difficult, especially with Pipelines around.

          Pipeline "Declarative: Checkout SCM" stages don't even give me the option to set a browser so any changeLogSet generated from that event is browser-less because my repository URL does not contain "github.com" in it.

          It also gets complicated matching which changeLogSet instance belongs to which SCM/UserRemoteConfig instance if jobs are launched with shared pipeline libraries. These generate additional SCM instances for a job for each library repository that is checked out.

          Trevor Howard added a comment - - edited So the bad links were being generated by having a value assigned to GitHubProjectProperty in the job. It'd be nice to know which SCM/UserRemoteConfig instance a ChangeLogSet is generated from. If a browser is not set then generating accurate reports is very difficult, especially with Pipelines around. Pipeline "Declarative: Checkout SCM" stages don't even give me the option to set a browser so any changeLogSet generated from that event is browser-less because my repository URL does not contain "github.com" in it. It also gets complicated matching which changeLogSet instance belongs to which SCM/UserRemoteConfig instance if jobs are launched with shared pipeline libraries. These generate additional SCM instances for a job for each library repository that is checked out.

            Unassigned Unassigned
            tahoward Trevor Howard
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: