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

Duplicate ChangeLog on Jenkins builds even though builds are not executed in parallel

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Critical
    • Resolution: Unresolved
    • Labels:
      None
    • Environment:
      Jenkins ver. 2.121.3

      Git Changelog plugin version  2.16

      git-client 2.7.0

      git 3.7.1
    • Similar Issues:

      Description

      The Git ChangeLog's are repeated in the builds as shown below example.

      Note:

      We are doing checkout of the previous revision to do the comparision of scripts.

      But the changelog is set to false for the previous revision checkout.

      Hence it shows multiple "Git Build Data". But Change log is repeating somehow for every next build executed, even though the next build is executed after 2 days.

      Example ChangeLog

      #12 (Jan 31, 2019 8:00:00 AM)
      [JIRA-XXX]: Added validation — User3
      [JIRA-XXX]: Code Clean up — User1
      [JIRA-XXX]: Cleanup — User2
      [JIRA-XXX]: State model and final cleanup - User1

      #10 (Jan 28, 2019 8:00:00 AM)
      [JIRA-XXX]: Added validation — User3
      [JIRA-XXX]: Code Clean up — User1
      [JIRA-XXX]: Cleanup — User2

      #9 (Jan 27, 2019 8:00:00 AM)
      [JIRA-XXX]: Added validation — User3

        Attachments

          Activity

          Hide
          markewaite Mark Waite added a comment -

          You mention that "changelog is set to false for the previous revision checkout". In what context is changelog set to false? For example, did you use a command like the following in your Pipeline:

          git changelog: false, url: 'https://github.com/MarkEWaite/jenkins-bugs.git'
          

          or did you use the more verbose checkout syntax like this:

          checkout changelog: false, 
              scm: [$class: 'GitSCM', 
                       branches: [[name: '*/master']], 
                       doGenerateSubmoduleConfigurations: false, 
                       extensions: [[$class: 'CloneOption', honorRefspec: true, noTags: true, reference: '/var/lib/git/mwaite/bugs/jenkins-bugs.git', shallow: false]], 
                       gitTool: 'Default', 
                       submoduleCfg: [], 
                       userRemoteConfigs: [[refspec: '+refs/heads/master:refs/remotes/origin/master', 
                       url: 'https://github.com/MarkEWaite/jenkins-bugs']]]
          

          In the workflow scm step plugin README, it says:

          By default each build will show changes from the previous build in its changelog as usual, and you can see an overall changelog on the project index page. You may specify changelog: false to disable changelog generation if it is not of interest, or too large to compute efficiently.

          Based on that text from the README, I would have assumed that your decision to set changelog to false means that the changelog is not being computed. If it is not being computed, then it may repeat or not repeat or be useful or not useful. If the changelog is important to you, why did you disable changelog generation?

          Based on the phrasing of the bug report, I think you want this to be assigned to the workflow-scm-step plugin, rather than assigning it to core, git plugin, and workflow-scm-step plugins. However, I'm not entirely sure that is the case.

          Is your concern about the duplication of the build data that is presented in the user interface for the job? In the example you gave, I assume that build 9 had completed before build 10 started, so you were expecting that "Added validation - User3" would not appear in the changelog for build 10 since it was already included in the completed and successful build 9.

          Is your concern about the results in a change log generated by the git changelog plugin?

          Please provide more details so that others can understand what you are expecting and how to duplicate the problem.

          Show
          markewaite Mark Waite added a comment - You mention that "changelog is set to false for the previous revision checkout". In what context is changelog set to false? For example, did you use a command like the following in your Pipeline: git changelog: false, url: 'https://github.com/MarkEWaite/jenkins-bugs.git' or did you use the more verbose checkout syntax like this: checkout changelog: false, scm: [$class: 'GitSCM', branches: [[name: '*/master']], doGenerateSubmoduleConfigurations: false, extensions: [[$class: 'CloneOption', honorRefspec: true, noTags: true, reference: '/var/lib/git/mwaite/bugs/jenkins-bugs.git', shallow: false]], gitTool: 'Default', submoduleCfg: [], userRemoteConfigs: [[refspec: '+refs/heads/master:refs/remotes/origin/master', url: 'https://github.com/MarkEWaite/jenkins-bugs']]] In the workflow scm step plugin README , it says: By default each build will show changes from the previous build in its changelog as usual, and you can see an overall changelog on the project index page. You may specify changelog: false to disable changelog generation if it is not of interest, or too large to compute efficiently. Based on that text from the README, I would have assumed that your decision to set changelog to false means that the changelog is not being computed. If it is not being computed, then it may repeat or not repeat or be useful or not useful. If the changelog is important to you, why did you disable changelog generation? Based on the phrasing of the bug report, I think you want this to be assigned to the workflow-scm-step plugin, rather than assigning it to core, git plugin, and workflow-scm-step plugins. However, I'm not entirely sure that is the case. Is your concern about the duplication of the build data that is presented in the user interface for the job? In the example you gave, I assume that build 9 had completed before build 10 started, so you were expecting that "Added validation - User3" would not appear in the changelog for build 10 since it was already included in the completed and successful build 9. Is your concern about the results in a change log generated by the git changelog plugin? Please provide more details so that others can understand what you are expecting and how to duplicate the problem.
          Hide
          hariprasadnr9 hariprasad Narnavara, added a comment -

          Hello Mark Waite,

          Thank for the quick response.

          We are doing the more verbose checkout using the cipa library (https://github.com/shasait/cipa/blob/master/src/de/hasait/cipa/activity/CheckoutActivity.groovy).

           

          Our multiple checkouts include:

          • Checkout of current revision which has triggered the build 
          • Checkout of previous revision (which is tagged for release) to compare the Data Changes.
          • Also pipeline source checkouts.

          Out of these 3 checkout's we set changelog:false for the previous tagged revision checkout, Since the changes from this changelog are not required. 

          But our job is somehow picking up the changelog from the Previous Build. and we are not doing checkout of previous revision.

          Our Concerns are:

          1. The Duplicate changelog is presented in the User Interface of the job.
          2. The email trigger is sent to all the users of the duplicated changelog, when there is a test failures/build failures.

           

          We are not using the Git Changelog plugin for this since it just display the detailed changelog and doesn't fix our issue.

          I hope you i am able to answer all yours questions.

          Please recommend if this has issue is with specific plugin Since we are not sure what is causing this duplicates and how jenkins changelog works when we are performing multiple checkouts.

           

          Thanks,

          Hariprasad

           

          Show
          hariprasadnr9 hariprasad Narnavara, added a comment - Hello Mark Waite , Thank for the quick response. We are doing the more verbose checkout using the cipa library ( https://github.com/shasait/cipa/blob/master/src/de/hasait/cipa/activity/CheckoutActivity.groovy).   Our multiple checkouts include: Checkout of current revision which has triggered the build  Checkout of previous revision (which is tagged for release) to compare the Data Changes. Also pipeline source checkouts. Out of these 3 checkout's we set changelog:false for the previous tagged revision checkout, Since the changes from this changelog are not required.  But our job is somehow picking up the changelog from the Previous Build. and we are not doing checkout of previous revision. Our Concerns are: The Duplicate changelog is presented in the User Interface of the job. The email trigger is sent to all the users of the duplicated changelog, when there is a test failures/build failures.   We are not using the Git Changelog plugin for this since it just display the detailed changelog and doesn't fix our issue. I hope you i am able to answer all yours questions. Please recommend if this has issue is with specific plugin Since we are not sure what is causing this duplicates and how jenkins changelog works when we are performing multiple checkouts.   Thanks, Hariprasad  
          Hide
          markewaite Mark Waite added a comment -

          Thanks for the answers. I suspect that means you want the workflow scm step plugin since it provides the changelog: false keyword. I've removed the git plugin and core from the component list.

          Show
          markewaite Mark Waite added a comment - Thanks for the answers. I suspect that means you want the workflow scm step plugin since it provides the changelog: false keyword. I've removed the git plugin and core from the component list.
          Hide
          thorstenrohde Thorsten Rohde added a comment - - edited

          Hi,

          I am in the same company as Hariprasad. Probably we found a workaround for this issue.

          Problem for us is the method:

          hudson.plugins.git.GitSCM .getBuildData(Run build)

          It takes the BuildData by branch names and we have two BuildData (because of two different checkouts in the same repo) objects containing the same branch name. Only for one checkout we calculate the changelog.
          In our case most of the time the wrong BuildData object was returned and used for change log calculation.

          Another problem for us in the method getBuildData is the line "build = build.getPreviousBuild();" 
          We do not need the previous build but the previous successful (yellow or green) build because we assign the failing tests to developers automatically.

           

          Solution for us:

          • delete both BuildData objects directly after checkout. Remember the one we need for change log generation
          • Add and store the BuildData we need for change log calculation after all tests are executed

          Now the next build can only get the right BuildData object and the changelog is calculated correctly

           

          Show
          thorstenrohde Thorsten Rohde added a comment - - edited Hi, I am in the same company as Hariprasad. Probably we found a workaround for this issue. Problem for us is the method: hudson.plugins.git.GitSCM .getBuildData(Run build) It takes the BuildData by branch names and we have two BuildData (because of two different checkouts in the same repo) objects containing the same branch name. Only for one checkout we calculate the changelog. In our case most of the time the wrong BuildData object was returned and used for change log calculation. Another problem for us in the method getBuildData is the line "build = build.getPreviousBuild();"  We do not need the previous build but the previous successful (yellow or green) build because we assign the failing tests to developers automatically.   Solution for us: delete both BuildData objects directly after checkout. Remember the one we need for change log generation Add and store the BuildData we need for change log calculation after all tests are executed Now the next build can only get the right BuildData object and the changelog is calculated correctly  

            People

            • Assignee:
              Unassigned
              Reporter:
              hariprasadnr9 hariprasad Narnavara,
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated: