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

SVN changelog per build not taking into account locations of script vs. checkout step

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Cannot Reproduce
    • Labels:
      None
    • Environment:
      CentOS 7.1
      Jenkins ver. 1.631
      Workflow plugin 1.10.1
    • Similar Issues:

      Description

      For the sake of argument let's say you have simple single stage build

      #1 build is triggered - executing stage 1
      #2 build is triggered - waiting for #1 (there were SVN changes #22, #23)
      #3 build is triggered - Superseds #2, waiting for #1 (there were SVN changes #24, #25)

      Build #2 was never executed, so SVN update was actually never triggered (General SCM step is inside the stage this build was waiting for). But still the revisions #22, #23 are in changelog of build #2.

      Build #3 actually did the SVN update. In console output I can see that files from revision #22 and #23 were updated. But ONLY revision #24, #25 are part of the changelog.

      This cannot be intended behaviour right?

        Attachments

          Activity

          Hide
          jglick Jesse Glick added a comment -

          If you have a simple inline script definition, build #3 will show SVN changes #22–25, since that is what the checkout scm: … step will be updating.

          If you are using a script loaded from SCM (and that SCM is in fact the same Subversion repository as the checkout step is using), then the first update will occur before the defined script even starts. Thus build #2 will show SVN changes #22–23 and build #3 will show changes #24–25.

          Similarly, if you are using a multibranch workflow, the checkout to get Jenkinsfile occurs before the script starts, so each build will be listed as including some SVN changes.

          Show
          jglick Jesse Glick added a comment - If you have a simple inline script definition, build #3 will show SVN changes #22–25, since that is what the checkout scm: … step will be updating. If you are using a script loaded from SCM (and that SCM is in fact the same Subversion repository as the checkout step is using), then the first update will occur before the defined script even starts. Thus build #2 will show SVN changes #22–23 and build #3 will show changes #24–25. Similarly, if you are using a multibranch workflow, the checkout to get Jenkinsfile occurs before the script starts, so each build will be listed as including some SVN changes.
          Hide
          vehovmar Martin Vehovsky added a comment - - edited

          How can you close this, saying this inconsistent behaviour is ok??

          Off course we use second option, just because having job definitions in SCM is quite convenient.

          I have to say, that it's pretty crappy behaviour, you can't say nothing about your build with certainty as you know NOTHING about what what changes did actually made it to your build!

          Really really disappointed about this!

          Show
          vehovmar Martin Vehovsky added a comment - - edited How can you close this, saying this inconsistent behaviour is ok?? Off course we use second option, just because having job definitions in SCM is quite convenient. I have to say, that it's pretty crappy behaviour, you can't say nothing about your build with certainty as you know NOTHING about what what changes did actually made it to your build! Really really disappointed about this!
          Hide
          jglick Jesse Glick added a comment -

          we use second option, just because having job definitions in SCM is quite convenient

          Right. So in that case it is correct that build #2 shows SVN changes #22–23: those may in fact have included modifications to the Workflow script which may have affected how build #2 ran.

          you know nothing about what changes did actually make it into your build

          Of course you do. As with any series of builds of a project using an SCM checking out from a specific branch, a build is assumed to include all changes listed in earlier builds, plus whatever is listed in its own changelog. Whether some of the earlier builds ran all the way to completion, or terminated early, is not relevant.

          Show
          jglick Jesse Glick added a comment - we use second option, just because having job definitions in SCM is quite convenient Right. So in that case it is correct that build #2 shows SVN changes #22–23: those may in fact have included modifications to the Workflow script which may have affected how build #2 ran. you know nothing about what changes did actually make it into your build Of course you do. As with any series of builds of a project using an SCM checking out from a specific branch, a build is assumed to include all changes listed in earlier builds, plus whatever is listed in its own changelog. Whether some of the earlier builds ran all the way to completion, or terminated early, is not relevant.
          Hide
          vehovmar Martin Vehovsky added a comment -

          No, no, no they definitely could not! That is why I specify SCM path in job config as for example /trunk/tools/jenkins/worflow. Changes in that and only that folder could influence the workflow script itself.

          Imagine that your build will fail and you want to investigate the reason. You will check the changelog for this build and no you are not finished you will have to check all the other builds that did NOTHING but containing changelog informations that was really taken to account in this build.

          Even more, you can't even send email to possible culprits because you have no way of knowing who that is really. You would blame someone for breaking the build, but the real revision that broke it would be in some previous builds.

          Looks to me that you are just trying to justify current implementation. Which is very cumbersome for users of your product.

          This should be reopened.

          Show
          vehovmar Martin Vehovsky added a comment - No, no, no they definitely could not! That is why I specify SCM path in job config as for example /trunk/tools/jenkins/worflow . Changes in that and only that folder could influence the workflow script itself. Imagine that your build will fail and you want to investigate the reason. You will check the changelog for this build and no you are not finished you will have to check all the other builds that did NOTHING but containing changelog informations that was really taken to account in this build. Even more, you can't even send email to possible culprits because you have no way of knowing who that is really. You would blame someone for breaking the build, but the real revision that broke it would be in some previous builds. Looks to me that you are just trying to justify current implementation. Which is very cumbersome for users of your product. This should be reopened.
          Hide
          jglick Jesse Glick added a comment -

          Need to review behavior in the special case of SubversionSCM with distinct locations for the Workflow script vs. what is passed to checkout. getKey() is implemented to take locations into account, so these ought to be considered distinct SCMs, but perhaps they are being conflated somehow.

          you can't even send email to possible culprits because you have no way of knowing who that is really. You would blame someone for breaking the build, but the real revision that broke it would be in some previous builds.

          That is true of any CI system in which developers are allowed to push directly to an integration branch (like trunk). The only way to prevent that is to gate all commits by CI status, as Workflow: Multibranch would help you do. (Currently there is no plugin for it to automatically merge branches that pass.)

          Show
          jglick Jesse Glick added a comment - Need to review behavior in the special case of SubversionSCM with distinct locations for the Workflow script vs. what is passed to checkout . getKey() is implemented to take locations into account, so these ought to be considered distinct SCMs, but perhaps they are being conflated somehow. you can't even send email to possible culprits because you have no way of knowing who that is really. You would blame someone for breaking the build, but the real revision that broke it would be in some previous builds. That is true of any CI system in which developers are allowed to push directly to an integration branch (like trunk ). The only way to prevent that is to gate all commits by CI status, as Workflow: Multibranch would help you do. (Currently there is no plugin for it to automatically merge branches that pass.)
          Hide
          vehovmar Martin Vehovsky added a comment -

          Alright it's all a little differently.

          First of all, very sorry for misleading info, colleague changed SCM path in job config to /trunk.

          Interesting is why, because we had no changelogs on the workflow job at all. (just changes in the /trunk/tools/jenkins/worflow)

          It was probably caused by syntax we used:

          checkout poll: true,
          scm: [$class : 'SubversionSCM',
          ...
          ]

          I regenerated, using the syntax from Snippet Generator and all looks good now!

          Show
          vehovmar Martin Vehovsky added a comment - Alright it's all a little differently. First of all, very sorry for misleading info, colleague changed SCM path in job config to /trunk . Interesting is why, because we had no changelogs on the workflow job at all . (just changes in the /trunk/tools/jenkins/worflow ) It was probably caused by syntax we used: checkout poll: true, scm: [$class : 'SubversionSCM', ... ] I regenerated, using the syntax from Snippet Generator and all looks good now!
          Hide
          vehovmar Martin Vehovsky added a comment - - edited

          All looks good except the polling.

          1/ Polling log shows only /trunk/tools/jenkins/worflow and not /trunk

          2/ exacly same polling log for 3 builds in a row:

          Example:
          Polling Log

          Started on 06-Nov-2015 11:25:06
          Received SCM poll call on master for 0000-icm_job_flow on 06-Nov-2015 11:25:06
          <svn_path>trunk/tools/jenkins/workflow is at revision 24,266
          (changed from 24,264)
          Done. Took 1.6 sec
          Changes found

          Show
          vehovmar Martin Vehovsky added a comment - - edited All looks good except the polling. 1/ Polling log shows only /trunk/tools/jenkins/worflow and not /trunk 2/ exacly same polling log for 3 builds in a row: Example: Polling Log Started on 06-Nov-2015 11:25:06 Received SCM poll call on master for 0000-icm_job_flow on 06-Nov-2015 11:25:06 <svn_path>trunk/tools/jenkins/workflow is at revision 24,266 (changed from 24,264) Done. Took 1.6 sec Changes found
          Hide
          vehovmar Martin Vehovsky added a comment -

          Cannot reproduce anymore..

          Show
          vehovmar Martin Vehovsky added a comment - Cannot reproduce anymore..

            People

            • Assignee:
              Unassigned
              Reporter:
              vehovmar Martin Vehovsky
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: