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

SCM change sets have the same items despite their relevant updates being different

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      Much like JENKINS-48479 some kind of duplication also occurs when one build causes two updates of the @script directory and the workspace coming from the same repository, but the updates start from different revision (e.g. one from 10 to 15 and second from 12 to 15). Items contained in the change sets should be different then, but are the same.

      It's easy to reproduce when there's only a single executor available. You need a Multibranch Pipeline configured with Jenkinsfile from SVN repository and a stage with checkout(scm) call in the file.

      Reproduction steps

      1. Start a build that will take a long time or pause it during the execution.
      2. Start a second build that will update the @script directory and then stop to wait for an available executor.
      3. Abort the second build, it will leave the @script directory updated, but the workspace at an older revision.
      4. Let the first build finish or abort it.
      5. Start a third build that will update the @script directory and then the workspace.
      6. Both change sets available to the script will only have items that were updated during the @script directory update in step 5 despite updating from different revisions. In case the @script update from step 5 doesn't update anything, no change sets will be available whatsoever.

      Remarks

      • Using a separate SubversionSCM instance in checkout call doesn't change anything.

        Attachments

          Activity

          vennor Vennor created issue -
          vennor Vennor made changes -
          Field Original Value New Value
          Description Much like JENKINS-48479 some kind of duplication also occurs when one build causes two updates of the _@script_ directory and the workspace coming from the same repository, but the updates start from different revision (e.g. 10 to 15 and 12 to 15) or end up on different revision (e.g. 10 to 13 and 10 to 15). Items contained in the change sets should be different then, but are the same.

          It's easy to reproduce when there's only a single executor available. You need a Multibranch Pipeline configured with Jenkinsfile from SVN repository and a stage with {{checkout(scm)}} call in the file.

          The first situation
           # Start a build that will take a long time or pause it during the execution.
           # Start a second build that will update the _@script_ directory and then stop to wait for an available executor.
           # Abort the second build, it will leave the _@script_ directory updated, but leave the workspace at an older revision.
           # Let the first build finish or abort it.
           # Start a third build that will update the _@script_ directory and then the workspace.
           # Both change sets available to the script will only have items that were updated during the _@script_ directory update in step 5 despite updating from different revisions. In case the _@script_ update from step 5 doesn't update anything, no change sets will be available whatsoever.

          The second situation
           # Start a build that will take a long time or pause it during the execution.
           # Start a second build that will update the _@script_ directory and then stop to wait for an available executor.
           # Commit something to the repository.
           # Let the first build finish or abort it.
           # Let the second build continue and update the workspace to a more recent revision than the _@script_ directory due to the commit from step 3.
           # Both change sets available to the script will only have items that were updated during the _@script_ directory update in step 2 despite updating to different revisions. In case the _@script_ update from step 2 doesn't update anything, no change sets will be available whatsoever.

          Using a separate {{SubversionSVM}} instance in {{checkout}} call doesn't change anything.
          Much like JENKINS-48479 some kind of duplication also occurs when one build causes two updates of the _@script_ directory and the workspace coming from the same repository, but the updates start from different revision (e.g. 10 to 15 and 12 to 15) or end up on different revision (e.g. 10 to 13 and 10 to 15). Items contained in the change sets should be different then, but are the same.

          It's easy to reproduce when there's only a single executor available. You need a Multibranch Pipeline configured with Jenkinsfile from SVN repository and a stage with {{checkout(scm)}} call in the file.

          The first situation
           # Start a build that will take a long time or pause it during the execution.
           # Start a second build that will update the _@script_ directory and then stop to wait for an available executor.
           # Abort the second build, it will leave the _@script_ directory updated, but leave the workspace at an older revision.
           # Let the first build finish or abort it.
           # Start a third build that will update the _@script_ directory and then the workspace.
           # Both change sets available to the script will only have items that were updated during the _@script_ directory update in step 5 despite updating from different revisions. In case the _@script_ update from step 5 doesn't update anything, no change sets will be available whatsoever.

          The second situation
           # Start a build that will take a long time or pause it during the execution.
           # Start a second build that will update the _@script_ directory and then stop to wait for an available executor.
           # Commit something to the repository.
           # Let the first build finish or abort it.
           # Let the second build continue and update the workspace to a more recent revision than the _@script_ directory due to the commit from step 3.
           # Both change sets available to the script will only have items that were updated during the _@script_ directory update in step 2 despite updating to different revisions. In case the _@script_ update from step 2 doesn't update anything, no change sets will be available whatsoever.

          Using a separate {{SubversionSCM}} instance in {{checkout}} call doesn't change anything.
          vennor Vennor made changes -
          Description Much like JENKINS-48479 some kind of duplication also occurs when one build causes two updates of the _@script_ directory and the workspace coming from the same repository, but the updates start from different revision (e.g. 10 to 15 and 12 to 15) or end up on different revision (e.g. 10 to 13 and 10 to 15). Items contained in the change sets should be different then, but are the same.

          It's easy to reproduce when there's only a single executor available. You need a Multibranch Pipeline configured with Jenkinsfile from SVN repository and a stage with {{checkout(scm)}} call in the file.

          The first situation
           # Start a build that will take a long time or pause it during the execution.
           # Start a second build that will update the _@script_ directory and then stop to wait for an available executor.
           # Abort the second build, it will leave the _@script_ directory updated, but leave the workspace at an older revision.
           # Let the first build finish or abort it.
           # Start a third build that will update the _@script_ directory and then the workspace.
           # Both change sets available to the script will only have items that were updated during the _@script_ directory update in step 5 despite updating from different revisions. In case the _@script_ update from step 5 doesn't update anything, no change sets will be available whatsoever.

          The second situation
           # Start a build that will take a long time or pause it during the execution.
           # Start a second build that will update the _@script_ directory and then stop to wait for an available executor.
           # Commit something to the repository.
           # Let the first build finish or abort it.
           # Let the second build continue and update the workspace to a more recent revision than the _@script_ directory due to the commit from step 3.
           # Both change sets available to the script will only have items that were updated during the _@script_ directory update in step 2 despite updating to different revisions. In case the _@script_ update from step 2 doesn't update anything, no change sets will be available whatsoever.

          Using a separate {{SubversionSCM}} instance in {{checkout}} call doesn't change anything.
          Much like JENKINS-48479 some kind of duplication also occurs when one build causes two updates of the _@script_ directory and the workspace coming from the same repository, but the updates start from different revision (e.g. one from 10 to 15 and second from 12 to 15). Items contained in the change sets should be different then, but are the same.

          It's easy to reproduce when there's only a single executor available. You need a Multibranch Pipeline configured with Jenkinsfile from SVN repository and a stage with {{checkout(scm)}} call in the file.

          Reproduction steps
           # Start a build that will take a long time or pause it during the execution.
           # Start a second build that will update the _@script_ directory and then stop to wait for an available executor.
           # Abort the second build, it will leave the _@script_ directory updated, but the workspace at an older revision.
           # Let the first build finish or abort it.
           # Start a third build that will update the _@script_ directory and then the workspace.
           # Both change sets available to the script will only have items that were updated during the _@script_ directory update in step 5 despite updating from different revisions. In case the _@script_ update from step 5 doesn't update anything, no change sets will be available whatsoever.

          Remarks
          * Using a separate {{SubversionSCM}} instance in {{checkout}} call doesn't change anything.
          vivek Vivek Pandey made changes -
          Labels changeset checkout jenkinsfile pipeline scm subversion svn update changeset checkout jenkinsfile pipeline scm subversion svn triaged-2018-11 update

            People

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

              Dates

              • Created:
                Updated: