Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-48479

SCM change sets have the same URL and revision despite coming from different repositories

    Details

    • Similar Issues:

      Description

      Recently I started using Multibranch Pipeline jobs and set up a shared library to avoid code duplication. I have library changes included and the library implicitly loaded, but explicit loading from the Jenkinsfile bears the same effect.

      When writing templates for messages with repository changes after each build I discovered that both available change sets have the same URL and revision.

      My main checkout located in the Jenkinsfile has its changelog parameter set to false, so I suppose that the two change sets are related to the @script and @libs checkouts which in my case come from two different repositories.

      It might be connected to JENKINS-45815, but in this case it's not me who's doing the checkout.

       

      Reproduction steps are as follows.

      1. Create a Multibranch Pipeline, configure with repository A, use a Jenkinsfile with the code below.
      2. Add a global shared library under Configure System, Global Pipeline Libraries, cofigure with a different repository B, make sure that "Load implicitly" and "Include @Library changes in job recent changes" are checked.
      3. Commit some changes to both repositories so that change sets are created during the build.
      4. Start a build and watch the output.

       

      Here is the code I used to test the issue.

      currentBuild.changeSets.each{ cs ->
          echo "cs = ${cs}"
          cs.revisionMap.each{ k, v ->
              echo "* k = ${k}, v = ${v}"
          }
      }

      And here's the output I got. These are different change sets and they contain commits from different repositories with valid descriptions. Alas, the data contained in revisions and revisionMap is the same in both cases, despite one of them coming from A repository and the second from B repository.

      [Pipeline] echo
      cs = hudson.scm.SubversionChangeLogSet@58d9474d
      [Pipeline] echo
      * k = https://X/A/trunk, v = 56784
      [Pipeline] echo
      cs = hudson.scm.SubversionChangeLogSet@d544c46
      [Pipeline] echo
      * k = https://X/A/trunk, v = 56784

      I tried using the raw build, too, but it contains the same change set objects.

        Attachments

          Activity

          vennor Vennor created issue -
          abayer Andrew Bayer made changes -
          Field Original Value New Value
          Component/s workflow-cps-global-lib-plugin [ 21714 ]
          Component/s workflow-job-plugin [ 21716 ]
          Component/s pipeline [ 21692 ]
          vennor Vennor made changes -
          Description Recently I started using Multibranch Pipeline jobs and set up a shared library to avoid code duplication. I have library changes included and the library implicitly loaded, but explicit loading from the Jenkinsfile bears the same effect.

          When writing templates for messages with repository changes after each build I discovered that both available change sets have the same URL and revision.

          My main checkout located in the Jenkinsfile has its {{changelog}} parameter set to {{false}}, so I suppose that the two change sets come from the {{@script}} and {{@libs}} checkouts which in my case come from two different repositories.

          It might be connected to JENKINS-45815, but in this case it's not me who's doing the checkout.

           

          Reproduction steps are as follows.
           # Create a Multibranch Pipeline, configure with repository A, use a Jenkinsfile with the code below.
           # Add a global shared library under _Configure System_, _Global Pipeline Libraries_, cofigure with a different repository B, make sure that "Load implicitly" and "Include @Library changes in job recent changes" are checked.
           # Commit some changes to both repositories so that change sets are created during the build.
           # Start a build and watch the output.

           

          Here is the code I used to test the issue.
          {code:java}
          currentBuild.changeSets.each{ cs ->
              echo "cs = ${cs}"
              cs.revisionMap.each{ k, v ->
                  echo "* k = ${k}, v = ${v}"
              }
          }{code}
          And here's the output I got. These are different change sets and they contain commits from different repositories with valid descriptions. Alas, the data contained in {{revisions}} and {{revisionMap}} is the same in both cases, despite one of them coming from A repository and the second from B repository.
          {noformat}
          [Pipeline] echo
          cs = hudson.scm.SubversionChangeLogSet@58d9474d
          [Pipeline] echo
          * k = https://X/A/trunk, v = 56784
          [Pipeline] echo
          cs = hudson.scm.SubversionChangeLogSet@d544c46
          [Pipeline] echo
          * k = https://X/A/trunk, v = 56784{noformat}
          I tried using the raw build, too, but it contains the same change set objects.
          Recently I started using Multibranch Pipeline jobs and set up a shared library to avoid code duplication. I have library changes included and the library implicitly loaded, but explicit loading from the Jenkinsfile bears the same effect.

          When writing templates for messages with repository changes after each build I discovered that both available change sets have the same URL and revision.

          My main checkout located in the Jenkinsfile has its {{changelog}} parameter set to {{false}}, so I suppose that the two change sets are related to the {{@script}} and {{@libs}} checkouts which in my case come from two different repositories.

          It might be connected to -JENKINS-45815-, but in this case it's not me who's doing the checkout.

           

          Reproduction steps are as follows.
           # Create a Multibranch Pipeline, configure with repository A, use a Jenkinsfile with the code below.
           # Add a global shared library under _Configure System_, _Global Pipeline Libraries_, cofigure with a different repository B, make sure that "Load implicitly" and "Include @Library changes in job recent changes" are checked.
           # Commit some changes to both repositories so that change sets are created during the build.
           # Start a build and watch the output.

           

          Here is the code I used to test the issue.
          {code:java}
          currentBuild.changeSets.each{ cs ->
              echo "cs = ${cs}"
              cs.revisionMap.each{ k, v ->
                  echo "* k = ${k}, v = ${v}"
              }
          }{code}
          And here's the output I got. These are different change sets and they contain commits from different repositories with valid descriptions. Alas, the data contained in {{revisions}} and {{revisionMap}} is the same in both cases, despite one of them coming from A repository and the second from B repository.
          {noformat}
          [Pipeline] echo
          cs = hudson.scm.SubversionChangeLogSet@58d9474d
          [Pipeline] echo
          * k = https://X/A/trunk, v = 56784
          [Pipeline] echo
          cs = hudson.scm.SubversionChangeLogSet@d544c46
          [Pipeline] echo
          * k = https://X/A/trunk, v = 56784{noformat}
          I tried using the raw build, too, but it contains the same change set objects.
          vivek Vivek Pandey made changes -
          Labels changeset checkout pipeline scm shared-groovy-libraries subversion svn changeset checkout pipeline scm shared-groovy-libraries subversion svn triaged-2018-11

            People

            • Assignee:
              Unassigned
              Reporter:
              vennor Vennor
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: