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

another Jenkinsfile is used than reported to be used if 'rebuild from stage' is used

    Details

    • Sprint:
      Declarative backlog
    • Similar Issues:

      Description

      A very simple (attached) Jenkinsfile including 2 stages is used in a git multibranch project. To visualize the issue in stage 'two' the commands 'git show' and 'cat Jenkinsfile will be called'.

      To reproduce this issue the following steps are necessary:

      1) run job
      2) modify Jenkinsfile and commit/push it into git
      3) rerun job from stage 'two' 

       

      Running the job the first time, the log contains:

       

      Obtained Jenkinsfile from 2d9e9b6366fd0c3361cf831d37cfaca6b8318efc
      ...
      [Pipeline] stage[Pipeline] { (one)[Pipeline] script[Pipeline] {[Pipeline] echojenkins-simpletest2-3[Pipeline] }[Pipeline] // script[Pipeline] }[Pipeline] // stage
      [Pipeline] stage
      [Pipeline] { (two)
      [Pipeline] script
      [Pipeline] {
      [Pipeline] sh
      [workspace] Running shell script
      + git show
      commit 2d9e9b6366fd0c3361cf831d37cfaca6b8318efc

       

      Running it the second time:

       

      Obtained Jenkinsfile from d6182967fab6e27b5a43f517e62be5b4d5410099
      ...  
      [Pipeline] stage
      [Pipeline] { (one)Stage "one" skipped due to this build restarting at stage "two"[Pipeline] }[Pipeline] // stage[Pipeline]  stage[Pipeline] { (two)[Pipeline] script[Pipeline] {[Pipeline] sh[workspace] Running shell script
      + git show
      commit 2d9e9b6366fd0c3361cf831d37cfaca6b8318efc

       

      Conclusion

       

      The commit d6182 introduces a println in stage2. This print is missing in the second run and is not displayed by the output of 'cat Jenkinsfile'.

      It is clear, that the Jenkinsfile from 2d9e9 was used for the second run. However the log reports, that the Jenkinsfile was obtained from d6182.

      I would expect, that the Jenkinsfile from current HEAD (which is d6182 in my case) will be used for jobs 'restarted from stage' as printed in the logs. But the more critical thing is, that another Jenkinsfile is used for testing than reported in the logs. This makes the test log completely useless and ends up in big confusions by users.

        Attachments

          Activity

          manut Manuel Traut created issue -
          manut Manuel Traut made changes -
          Field Original Value New Value
          Description A very simple (attached) Jenkinsfile including 2 stages is used in a git multibranch project. Two visualize the issue in stage 2 'git show' and 'cat Jenkinsfile will be called'.

           

          To reproduce this issue the following steps are necessary:

          1) run job

          2) modify Jenkinsfile and commit/push it into git

          3) rerun job from stage 'two'

           

          Running the job the first time, the log contains:

           
          {color:#9a9999}Obtained Jenkinsfile from 2d9e9b6366fd0c3361cf831d37cfaca6b8318efc
          ...
          [Pipeline] stage{color}{color:#9a9999}[Pipeline] { (two){color}{color:#9a9999}[Pipeline] script{color}{color:#9a9999}[Pipeline] {{color}{color:#9a9999}[Pipeline] sh{color}[workspace] Running shell script
          + git show
          commit 2d9e9b6366fd0c3361cf831d37cfaca6b8318efc
          Running it the second time:
          {color:#9a9999}Obtained Jenkinsfile from d6182967fab6e27b5a43f517e62be5b4d5410099
          [Pipeline] stage{color}{color:#9a9999}[Pipeline] { (two){color}{color:#9a9999}[Pipeline] script{color}{color:#9a9999}[Pipeline] {{color}{color:#9a9999}[Pipeline] sh{color}[workspace] Running shell script
          + git show
          commit 2d9e9b6366fd0c3361cf831d37cfaca6b8318efc
          The commit d6182 introduces a println in stage2. This print is also missing in the second run. So the Jenkinsfile from 2d9e9 was used for the second run, but the log says something else. I would expect, that the Jenkinsfile from current HEAD will be used for jobs 'restarted from stage'.

          {color:#172b4d}Another Jenkinsfile is used for testing than reported in the logs. This makes the test log completely useless and ends up in big confusions by users.{color}

           
          A very simple (attached) Jenkinsfile including 2 stages is used in a git multibranch project. To visualize the issue in stage 'two' the commands 'git show' and 'cat Jenkinsfile will be called'.

          To reproduce this issue the following steps are necessary:

          1) run job
          2) modify Jenkinsfile and commit/push it into git
          3) rerun job from stage 'two' 

          *Running the job the first time, the log contains:*

          {color:#9a9999}Obtained Jenkinsfile from 2d9e9b6366fd0c3361cf831d37cfaca6b8318efc
           ...
           [Pipeline] stage{color}{color:#9a9999}[Pipeline] { (two){color}{color:#9a9999}[Pipeline] script{color}{color:#9a9999}[Pipeline] {{color}{color:#9a9999}[Pipeline] sh{color}[workspace] Running shell script
           + git show
           commit 2d9e9b6366fd0c3361cf831d37cfaca6b8318efc

          *Running it the second time:*

          {color:#9a9999}Obtained Jenkinsfile from d6182967fab6e27b5a43f517e62be5b4d5410099
           [Pipeline] stage{color}{color:#9a9999}[Pipeline] { (two){color}{color:#9a9999}[Pipeline] script{color}{color:#9a9999}[Pipeline] {{color}{color:#9a9999}[Pipeline] sh{color}[workspace] Running shell script
           + git show
           commit 2d9e9b6366fd0c3361cf831d37cfaca6b8318efc

          The commit d6182 introduces a println in stage2. This print is missing in the second run and is not displayed by the output of 'cat Jenkinsfile'.

          It is clear, that the Jenkinsfile from 2d9e9 was used for the second run. However the log reports, that the Jenkinsfile was obtained from d6182.

          I would expect, that the Jenkinsfile from current HEAD (which is d6182 in my case) will be used for jobs 'restarted from stage' as printed in the logs. But the more critical thing is, that a{color:#172b4d}nother Jenkinsfile is used for testing than reported in the logs. This makes the test log completely useless and ends up in big confusions by users.{color}
          manut Manuel Traut made changes -
          Description A very simple (attached) Jenkinsfile including 2 stages is used in a git multibranch project. To visualize the issue in stage 'two' the commands 'git show' and 'cat Jenkinsfile will be called'.

          To reproduce this issue the following steps are necessary:

          1) run job
          2) modify Jenkinsfile and commit/push it into git
          3) rerun job from stage 'two' 

          *Running the job the first time, the log contains:*

          {color:#9a9999}Obtained Jenkinsfile from 2d9e9b6366fd0c3361cf831d37cfaca6b8318efc
           ...
           [Pipeline] stage{color}{color:#9a9999}[Pipeline] { (two){color}{color:#9a9999}[Pipeline] script{color}{color:#9a9999}[Pipeline] {{color}{color:#9a9999}[Pipeline] sh{color}[workspace] Running shell script
           + git show
           commit 2d9e9b6366fd0c3361cf831d37cfaca6b8318efc

          *Running it the second time:*

          {color:#9a9999}Obtained Jenkinsfile from d6182967fab6e27b5a43f517e62be5b4d5410099
           [Pipeline] stage{color}{color:#9a9999}[Pipeline] { (two){color}{color:#9a9999}[Pipeline] script{color}{color:#9a9999}[Pipeline] {{color}{color:#9a9999}[Pipeline] sh{color}[workspace] Running shell script
           + git show
           commit 2d9e9b6366fd0c3361cf831d37cfaca6b8318efc

          The commit d6182 introduces a println in stage2. This print is missing in the second run and is not displayed by the output of 'cat Jenkinsfile'.

          It is clear, that the Jenkinsfile from 2d9e9 was used for the second run. However the log reports, that the Jenkinsfile was obtained from d6182.

          I would expect, that the Jenkinsfile from current HEAD (which is d6182 in my case) will be used for jobs 'restarted from stage' as printed in the logs. But the more critical thing is, that a{color:#172b4d}nother Jenkinsfile is used for testing than reported in the logs. This makes the test log completely useless and ends up in big confusions by users.{color}
          A very simple (attached) Jenkinsfile including 2 stages is used in a git multibranch project. To visualize the issue in stage 'two' the commands 'git show' and 'cat Jenkinsfile will be called'.

          To reproduce this issue the following steps are necessary:

          1) run job
           2) modify Jenkinsfile and commit/push it into git
           3) rerun job from stage 'two' 

          *Running the job the first time, the log contains:*
          {color:#9a9999}Obtained Jenkinsfile from {color:#172b4d}*2d9e9b6366fd0c3361cf831d37cfaca6b8318efc*{color}
          ...
          {color}{color:#9a9999}[Pipeline] stage{color}{color:#9a9999}[Pipeline] { (one){color}{color:#9a9999}[Pipeline] script{color}{color:#9a9999}[Pipeline] {{color}{color:#9a9999}[Pipeline] echo{color}jenkins-simpletest2-3{color:#9a9999}[Pipeline] }{color}{color:#9a9999}[Pipeline] // script{color}{color:#9a9999}[Pipeline] }{color}{color:#9a9999}[Pipeline] // stage
          [Pipeline] stage
          [Pipeline] { (two)
          [Pipeline] script
          [Pipeline] {
          [Pipeline] sh
          [workspace] Running shell script
           + git show
           commit *2d9e9b6366fd0c3361cf831d37cfaca6b8318efc* {color}
          *Running it the second time:*
          {color:#9a9999}Obtained Jenkinsfile from *d6182967fab6e27b5a43f517e62be5b4d5410099*
          ...  
          [Pipeline] stage{color}{color:#9a9999}[Pipeline] { (one){color}Stage "one" skipped due to this build restarting at stage "two"{color:#9a9999}[Pipeline] }{color}{color:#9a9999}[Pipeline] // stage
          {color}{color:#9a9999}[Pipeline]  stage
          {color}{color:#9a9999}[Pipeline] { (two)
          {color}{color:#9a9999}[Pipeline] script
          {color}{color:#9a9999}[Pipeline] {
          {color}{color:#9a9999}[Pipeline] sh
          {color}[workspace] Running shell script
           + git show
           commit 2d9e9b6366fd0c3361cf831d37cfaca6b8318efc
          *Conclusion*

          The commit *d6182* introduces a println in stage2. This print is missing in the second run and is not displayed by the output of 'cat Jenkinsfile'.

          It is clear, that the Jenkinsfile from *2d9e9* was used for the second run. However the log reports, that the Jenkinsfile was obtained from *d6182*.

          I would expect, that the Jenkinsfile from current *HEAD* (which is *d6182* in my case) will be used for jobs 'restarted from stage' as printed in the logs. But the more critical thing is, that a{color:#172b4d}nother Jenkinsfile is used for testing than reported in the logs. This makes the test log completely useless and ends up in big confusions by users.{color}
          manut Manuel Traut made changes -
          Description A very simple (attached) Jenkinsfile including 2 stages is used in a git multibranch project. To visualize the issue in stage 'two' the commands 'git show' and 'cat Jenkinsfile will be called'.

          To reproduce this issue the following steps are necessary:

          1) run job
           2) modify Jenkinsfile and commit/push it into git
           3) rerun job from stage 'two' 

          *Running the job the first time, the log contains:*
          {color:#9a9999}Obtained Jenkinsfile from {color:#172b4d}*2d9e9b6366fd0c3361cf831d37cfaca6b8318efc*{color}
          ...
          {color}{color:#9a9999}[Pipeline] stage{color}{color:#9a9999}[Pipeline] { (one){color}{color:#9a9999}[Pipeline] script{color}{color:#9a9999}[Pipeline] {{color}{color:#9a9999}[Pipeline] echo{color}jenkins-simpletest2-3{color:#9a9999}[Pipeline] }{color}{color:#9a9999}[Pipeline] // script{color}{color:#9a9999}[Pipeline] }{color}{color:#9a9999}[Pipeline] // stage
          [Pipeline] stage
          [Pipeline] { (two)
          [Pipeline] script
          [Pipeline] {
          [Pipeline] sh
          [workspace] Running shell script
           + git show
           commit *2d9e9b6366fd0c3361cf831d37cfaca6b8318efc* {color}
          *Running it the second time:*
          {color:#9a9999}Obtained Jenkinsfile from *d6182967fab6e27b5a43f517e62be5b4d5410099*
          ...  
          [Pipeline] stage{color}{color:#9a9999}[Pipeline] { (one){color}Stage "one" skipped due to this build restarting at stage "two"{color:#9a9999}[Pipeline] }{color}{color:#9a9999}[Pipeline] // stage
          {color}{color:#9a9999}[Pipeline]  stage
          {color}{color:#9a9999}[Pipeline] { (two)
          {color}{color:#9a9999}[Pipeline] script
          {color}{color:#9a9999}[Pipeline] {
          {color}{color:#9a9999}[Pipeline] sh
          {color}[workspace] Running shell script
           + git show
           commit 2d9e9b6366fd0c3361cf831d37cfaca6b8318efc
          *Conclusion*

          The commit *d6182* introduces a println in stage2. This print is missing in the second run and is not displayed by the output of 'cat Jenkinsfile'.

          It is clear, that the Jenkinsfile from *2d9e9* was used for the second run. However the log reports, that the Jenkinsfile was obtained from *d6182*.

          I would expect, that the Jenkinsfile from current *HEAD* (which is *d6182* in my case) will be used for jobs 'restarted from stage' as printed in the logs. But the more critical thing is, that a{color:#172b4d}nother Jenkinsfile is used for testing than reported in the logs. This makes the test log completely useless and ends up in big confusions by users.{color}
          A very simple (attached) Jenkinsfile including 2 stages is used in a git multibranch project. To visualize the issue in stage 'two' the commands 'git show' and 'cat Jenkinsfile will be called'.

          To reproduce this issue the following steps are necessary:

          1) run job
           2) modify Jenkinsfile and commit/push it into git
           3) rerun job from stage 'two' 

           

          *Running the job the first time, the log contains:*

           

          {color:#9a9999}Obtained Jenkinsfile from *2d9e9b6366fd0c3361cf831d37cfaca6b8318efc*{color}
           ...
           [Pipeline] stage{color:#9a9999}[Pipeline] { (one){color}{color:#9a9999}[Pipeline] script{color}{color:#9a9999}[Pipeline] {{color}{color:#9a9999}[Pipeline] echo{color}jenkins-simpletest2-3{color:#9a9999}[Pipeline] }{color}{color:#9a9999}[Pipeline] // script{color}{color:#9a9999}[Pipeline] }{color}{color:#9a9999}[Pipeline] // stage
           [Pipeline] stage
           [Pipeline] { (two)
           [Pipeline] script
           [Pipeline] {
           [Pipeline] sh
           [workspace] Running shell script
           + git show
           commit *2d9e9b6366fd0c3361cf831d37cfaca6b8318efc* {color}

           

          *Running it the second time:*

           

          {color:#9a9999}Obtained Jenkinsfile from *d6182967fab6e27b5a43f517e62be5b4d5410099*
           ...  
           [Pipeline] stage{color}{color:#9a9999}[Pipeline] { (one){color}Stage "one" skipped due to this build restarting at stage "two"{color:#9a9999}[Pipeline] }{color}{color:#9a9999}[Pipeline] // stage{color}{color:#9a9999}[Pipeline]  stage{color}{color:#9a9999}[Pipeline] { (two){color}{color:#9a9999}[Pipeline] script{color}{color:#9a9999}[Pipeline] {{color}{color:#9a9999}[Pipeline] sh{color}[workspace] Running shell script
           + git show
           commit 2d9e9b6366fd0c3361cf831d37cfaca6b8318efc

           

          *Conclusion*

           

          The commit *d6182* introduces a println in stage2. This print is missing in the second run and is not displayed by the output of 'cat Jenkinsfile'.

          It is clear, that the Jenkinsfile from *2d9e9* was used for the second run. However the log reports, that the Jenkinsfile was obtained from *d6182*.

          I would expect, that the Jenkinsfile from current *HEAD* (which is *d6182* in my case) will be used for jobs 'restarted from stage' as printed in the logs. But the more critical thing is, that a{color:#172b4d}nother Jenkinsfile is used for testing than reported in the logs. This makes the test log completely useless and ends up in big confusions by users.{color}
          Hide
          manut Manuel Traut added a comment -

          Can someone give me a reference to the related source-code. E.g. the commit introducing the 'restart from stage' feature. I have no idea where to look at..

          Show
          manut Manuel Traut added a comment - Can someone give me a reference to the related source-code. E.g. the commit introducing the 'restart from stage' feature. I have no idea where to look at..
          abayer Andrew Bayer made changes -
          Component/s pipeline-model-definition-plugin [ 21706 ]
          Component/s pipeline-stage-step-plugin [ 21709 ]
          Hide
          abayer Andrew Bayer added a comment -

          So there's a definite issue here - the misleading Obtained Jenkinsfile from d6182967fab6e27b5a43f517e62be5b4d5410099. When you restart from a stage, all inputs will be the same as the original run, including the SCM revision used for the Jenkinsfile and the checkout. It's properly using the right, original revision for the checkout, and is properly using the original revision for the Jenkinsfile, but it's reporting the old revision was used for the Jenkinsfile. I'll look into this.

          Show
          abayer Andrew Bayer added a comment - So there's a definite issue here - the misleading Obtained Jenkinsfile from d6182967fab6e27b5a43f517e62be5b4d5410099 . When you restart from a stage, all inputs will be the same as the original run, including the SCM revision used for the Jenkinsfile and the checkout. It's properly using the right, original revision for the checkout, and is properly using the original revision for the Jenkinsfile, but it's reporting the old revision was used for the Jenkinsfile. I'll look into this.
          abayer Andrew Bayer made changes -
          Labels stage-restart-improvements
          abayer Andrew Bayer made changes -
          Sprint Declarative backlog [ 621 ]
          vivek Vivek Pandey made changes -
          Labels stage-restart-improvements pipeline-triaged stage-restart-improvements

            People

            • Assignee:
              Unassigned
              Reporter:
              manut Manuel Traut
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated: