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

Duplicate ChangeLog on Jenkins builds for concurrent builds

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

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

      This is pipeline job and the build takes one hour to complete and hence below 3 build executed in parallel but i see the changelog is repeated.

      Versions used:

      Jenkins ver. 2.121.3

      Git Changelog plugin version  2.16

      git-client 2.7.0

      git 3.7.1

       

      ChangeLog

      #12 (Jan 29, 2019 8:59:07 AM)
      JIRA-XXX: Added validation — User3
      [JIRA-XXX] clean up — User1
      JIRA-XXX: Cleanup — User2
      JIRA-XXX: State model and final cleanup - user1

      #10 (Jan 29, 2019 8:54:55 AM)
      JIRA-XXX: Added validation — User3
      [JIRA-XXX] clean up — User1
      JIRA-XXX: Cleanup — User2

      #9 (Jan 29, 2019 8:45:43 AM)
      JIRA-XXX: Added validation — User3

        Attachments

          Activity

          Hide
          markewaite Mark Waite added a comment -

          The changelog wants to present the changes since the last completed build. Since the 3 jobs you listed all ran in parallel and had not completed. the changes list may be correct displaying it for each of the jobs.

          Show
          markewaite Mark Waite added a comment - The changelog wants to present the changes since the last completed build. Since the 3 jobs you listed all ran in parallel and had not completed. the changes list may be correct displaying it for each of the jobs.
          Hide
          hariprasadnr9 hariprasad Narnavara, added a comment - - edited

          Hello Mark Waite,

          Yes i understand that. Even i found out that the root cause of this is what is you mentioned.

           

          But in case the build fails i am fetching the emails from the change log and all the developer who did commits are notified.

          Instead only one developer who did the wrong commit at the end has to be notified.

           

          This is where i started to analyze why it notified also other developers which commited previous to the failing commit.

          Also for the developers its confusing when they look at change log since there are multiple commits.

          Hence displaying only the change from previous git revision/ previously triggered build makes sense instead of last completed build.

           

          Please let me know if there is any resolution to fix this issue.

           

          Thanks,

          Hariprasad

          Show
          hariprasadnr9 hariprasad Narnavara, added a comment - - edited Hello Mark Waite , Yes i understand that. Even i found out that the root cause of this is what is you mentioned.   But in case the build fails i am fetching the emails from the change log and all the developer who did commits are notified. Instead only one developer who did the wrong commit at the end has to be notified.   This is where i started to analyze why it notified also other developers which commited previous to the failing commit. Also for the developers its confusing when they look at change log since there are multiple commits. Hence displaying only the change from previous git revision/ previously triggered build makes sense instead of last completed build.   Please let me know if there is any resolution to fix this issue.   Thanks, Hariprasad
          Hide
          hariprasadnr9 hariprasad Narnavara, added a comment -

          Hello Kohsuke Kawaguchi

          Is it possible to fix this issue using Git ChangeLog Plugin or Last Changes plugin in Jenkins.

           

          Thanks,

          Hariprasad

          Show
          hariprasadnr9 hariprasad Narnavara, added a comment - Hello Kohsuke Kawaguchi Is it possible to fix this issue using Git ChangeLog Plugin or Last Changes plugin in Jenkins.   Thanks, Hariprasad
          Hide
          markewaite Mark Waite added a comment -

          hariprasad Narnavara, it is possible to avoid the issue by using pull requests rather than having everyone commit to a single branch. A multibranch Pipeline could then be configured to create and delete jobs each time a developer creates a pull request to the central repository. Refer to Jenkins Pipeline Fundamentals for a free self-paced Jenkins Pipeline training course.

          it is possible to fix the issue if you and your developers are willing to accept specific constraints. If you prevent parallel builds and if you immediately run a build each time a change is pushed to the central repository, then the attribution of build breaks will be absolutely clear. Most teams are unwilling to accept that delay.

          Another fix is to reduce the build time so that it takes much less time to complete a build. That decreases the time window where parallel jobs could be running and reduces the time from commit to completed build.

          There isn't any code in any of the plugins that I know which will detect that a parallel build has been started with some of the commits being already included in a running parallel build. It seems like the graph analysis to detect the condition is possible though I'm not sure how a user interface would be presented to the user to show them that earlier parallel builds are evaluating a subset of the changes Jenkins multibranch Pipeline is the best of the alternatives that I've listed.

          Show
          markewaite Mark Waite added a comment - hariprasad Narnavara, it is possible to avoid the issue by using pull requests rather than having everyone commit to a single branch. A multibranch Pipeline could then be configured to create and delete jobs each time a developer creates a pull request to the central repository. Refer to Jenkins Pipeline Fundamentals for a free self-paced Jenkins Pipeline training course. it is possible to fix the issue if you and your developers are willing to accept specific constraints. If you prevent parallel builds and if you immediately run a build each time a change is pushed to the central repository, then the attribution of build breaks will be absolutely clear. Most teams are unwilling to accept that delay. Another fix is to reduce the build time so that it takes much less time to complete a build. That decreases the time window where parallel jobs could be running and reduces the time from commit to completed build. There isn't any code in any of the plugins that I know which will detect that a parallel build has been started with some of the commits being already included in a running parallel build. It seems like the graph analysis to detect the condition is possible though I'm not sure how a user interface would be presented to the user to show them that earlier parallel builds are evaluating a subset of the changes Jenkins multibranch Pipeline is the best of the alternatives that I've listed.
          Hide
          hariprasadnr9 hariprasad Narnavara, added a comment -

          Hello Mark Waite

          Thank for the quick response.

          I see all the above solutions as a work around.

          We have the Jenkins Enterprise setup which can handle multiple builds to run in parallel.

          What would be the solution to fix this issue.?

          > A plugin should be implemented when extended git functionality

          > Jenkins need to implement this feature to handle the changeLog when build are running in parallle

           

           

          Show
          hariprasadnr9 hariprasad Narnavara, added a comment - Hello Mark Waite Thank for the quick response. I see all the above solutions as a work around. We have the Jenkins Enterprise setup which can handle multiple builds to run in parallel. What would be the solution to fix this issue.? > A plugin should be implemented when extended git functionality > Jenkins need to implement this feature to handle the changeLog when build are running in parallle    
          Hide
          markewaite Mark Waite added a comment -

          hariprasad Narnavara, I think multibranch pipelines are the best solution to the problem you're trying to solve.

          Each developer wants to see the results of their changes as applied to the master branch. They don't want the disruption of seeing the untested work of others intermixed with their changes. A single job and a single branch means that the developers need to decide which of the builds within the job are theirs and they need to decide which of the commits are theirs within that build.

          If instead each developer pushed their changes that needed to be evaluated to a separate branch for the change they were proposing, then the multibranch pipeline will automatically create a job dedicated to that branch. The developer will see only their changes on the new job for their new branch. They can add more commits, amend their commits, invite code review of their commits, and when those things are complete, they can merge that branch into the master branch. The multibranch pipeline insulates them from the unverified changes of others and allows them to do a better job of preparing their changes to be merged into the master branch.

          The multibranch pipeline works well with plain git (using branches), with Bitbucket (using branches, pull requests, and optionally forked repositories), with Gitea (using branches, pull requests, and optionally forked repositories), and with GitHub (using branches, pull requests, and optionally forked repositories). Please reconsider the capability of multibranch pipeline as a better solution to the problem you're trying to solve. It is something you can implement immediately and integrates well with Blue Ocean and other components.

          The free Jenkins Pipeline Fundamentals course introduces the multibranch pipeline concept very well.

          Show
          markewaite Mark Waite added a comment - hariprasad Narnavara, I think multibranch pipelines are the best solution to the problem you're trying to solve. Each developer wants to see the results of their changes as applied to the master branch. They don't want the disruption of seeing the untested work of others intermixed with their changes. A single job and a single branch means that the developers need to decide which of the builds within the job are theirs and they need to decide which of the commits are theirs within that build. If instead each developer pushed their changes that needed to be evaluated to a separate branch for the change they were proposing, then the multibranch pipeline will automatically create a job dedicated to that branch. The developer will see only their changes on the new job for their new branch. They can add more commits, amend their commits, invite code review of their commits, and when those things are complete, they can merge that branch into the master branch. The multibranch pipeline insulates them from the unverified changes of others and allows them to do a better job of preparing their changes to be merged into the master branch. The multibranch pipeline works well with plain git (using branches), with Bitbucket (using branches, pull requests, and optionally forked repositories), with Gitea (using branches, pull requests, and optionally forked repositories), and with GitHub (using branches, pull requests, and optionally forked repositories). Please reconsider the capability of multibranch pipeline as a better solution to the problem you're trying to solve. It is something you can implement immediately and integrates well with Blue Ocean and other components. The free Jenkins Pipeline Fundamentals course introduces the multibranch pipeline concept very well.

            People

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

              Dates

              • Created:
                Updated:
                Resolved: