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

Add option to run 'git bisect' to find which commit added new bugs

    Details

      Description

      Today, when you run find-bugs plug-in triggered by a git commit, you can't know exactly which commit added those bugs.
      It becomes especially difficult to know when a high volume of commits is pushed at once.

      find-bugs plug-in could have a new option to tick in the 'advanced section',
      which will do a 'git bisect' on the git commits that caused a new bug and display/email to commiter who did it.

      that would simply and automate the process of finding who wrote the bug.

        Activity

        Hide
        dfrankow Dan F added a comment -

        Anyone thought about working on this? Right now, our Jenkins emails out all sorts of emails about things breaking or being fixed, but doesn't pin-point the person who should fix breakages. Finding the responsible party seems more important than the "minor" on this issue.

        Show
        dfrankow Dan F added a comment - Anyone thought about working on this? Right now, our Jenkins emails out all sorts of emails about things breaking or being fixed, but doesn't pin-point the person who should fix breakages. Finding the responsible party seems more important than the "minor" on this issue.
        Hide
        dfrankow Dan F added a comment -

        Hi everyone. I need this bug/feature so much that I'm willing to pay for it.
        This offer is registered at FreedomSponsors (http://www.freedomsponsors.org/core/issue/33/add-option-to-run-git-bisect-to-find-which-commit-added-new-bugs).
        Once you solve it (according to the acceptance criteria described there), just create a FreedomSponsors account and mark it as resolved (oh, you'll need a Paypal account too)
        I'll then check it out and will gladly pay up!

        If anyone else would like to throw in a few bucks to elevate the priority on this issue, you should check out FreedomSponsors!

        I will try to get my employers to kick in more money.

        Show
        dfrankow Dan F added a comment - Hi everyone. I need this bug/feature so much that I'm willing to pay for it. This offer is registered at FreedomSponsors ( http://www.freedomsponsors.org/core/issue/33/add-option-to-run-git-bisect-to-find-which-commit-added-new-bugs ). Once you solve it (according to the acceptance criteria described there), just create a FreedomSponsors account and mark it as resolved (oh, you'll need a Paypal account too) I'll then check it out and will gladly pay up! If anyone else would like to throw in a few bucks to elevate the priority on this issue, you should check out FreedomSponsors! I will try to get my employers to kick in more money.
        Hide
        txemi txemi M added a comment - - edited

        I would love this feature. Now I am running bisect manually. It would be great that jenkins could tell which single commit broke compilation or unit test.

        Show
        txemi txemi M added a comment - - edited I would love this feature. Now I am running bisect manually. It would be great that jenkins could tell which single commit broke compilation or unit test.
        Hide
        swarren Stephen Warren added a comment -

        > Moreover (since this is only available with git), it should be an extension to the git plug-in.

        There's no reason at all that bisect should only be available with git. I think you're confusing the abstract concept of performing a bisect operation (which applies anywhere) with the specific "git bisect" command, which does only apply to git.

        I don't think "git bisect" (the command) should be used when implementing this feature, since "git bisect" would run multiple builds within a single Jenkins build, yet doing so would not integrate this feature well into Jenkins; I would explicitly expect every build performed as part of a bisect to be a separate Jenkins job, so that any downstream jobs (e.g. tests) get triggered by each build; one may be bisecting a failure in a downstream test, not in just the build.

        > These runs shouldn't really count as "builds", and shouldn't show up as such in the build history/statistics
        > of the job.

        Personally, I explicitly expect the opposite; if Jenkins builds a certain SCM commit, whether triggered by SCM polling, forced build, or as needed to perform a bisect, I expect that build to show up in all the normal places, and act just like any other build source.

        This would hopefully allow me to look at a build's/job's history, sorted in order of SCM commits, and clearly see which commit broke/fixed the build, all irrespective of what triggered the build at each of those SCM commits.

        Show
        swarren Stephen Warren added a comment - > Moreover (since this is only available with git), it should be an extension to the git plug-in. There's no reason at all that bisect should only be available with git. I think you're confusing the abstract concept of performing a bisect operation (which applies anywhere) with the specific "git bisect" command, which does only apply to git. I don't think "git bisect" (the command) should be used when implementing this feature, since "git bisect" would run multiple builds within a single Jenkins build, yet doing so would not integrate this feature well into Jenkins; I would explicitly expect every build performed as part of a bisect to be a separate Jenkins job, so that any downstream jobs (e.g. tests) get triggered by each build; one may be bisecting a failure in a downstream test, not in just the build. > These runs shouldn't really count as "builds", and shouldn't show up as such in the build history/statistics > of the job. Personally, I explicitly expect the opposite; if Jenkins builds a certain SCM commit, whether triggered by SCM polling, forced build, or as needed to perform a bisect, I expect that build to show up in all the normal places, and act just like any other build source. This would hopefully allow me to look at a build's/job's history, sorted in order of SCM commits, and clearly see which commit broke/fixed the build, all irrespective of what triggered the build at each of those SCM commits.
        Hide
        varosi Vassil Keremidchiev added a comment -

        It'll be very helpful a such feature!

        Show
        varosi Vassil Keremidchiev added a comment - It'll be very helpful a such feature!

          People

          • Assignee:
            Unassigned
            Reporter:
            eedri Eyal Edri
          • Votes:
            6 Vote for this issue
            Watchers:
            12 Start watching this issue

            Dates

            • Created:
              Updated: