• Icon: New Feature New Feature
    • Resolution: Unresolved
    • Icon: Major Major
    • claim-plugin

      This is an enhancement on the current claim plugin to support multiple claims of failed builds based on culprit selected.

      Suggested features to be added are:-

      1. List of culprits appear as list in drop down pertaining to the current build failed
      2. Scrollable panel that dynamically shows the list of other failed builds based on culprit selected from drop down
      3. Select All and Clear selection buttons to either select all builds or clear the selections.

      Added a sketch diagram of how it looks.

      Pull request link:
      https://github.com/jenkinsci/claim-plugin/pull/6

          [JENKINS-16671] Multiple Selective Claiming of Broken Builds

          kutzi added a comment -

          As commented on the pull request, I think that these are 2 different issue which should therefore also discussed separately:

          I: the ability to claim multiple, other builds - however this 'multiple' is defined
          II: the ability to claim builds for another user.

          I can see some value in I - however it has still to be discussed how the 'other' builds are defined. IMHO they should be at least be related in some kind to the current build. E.g. have an up/downstream relationship and/or use the same SCM change

          I'm still very sceptical about II. I cannot see any good reason why the other user shouldn't be able to claim the build for himself.

          kutzi added a comment - As commented on the pull request, I think that these are 2 different issue which should therefore also discussed separately: I: the ability to claim multiple, other builds - however this 'multiple' is defined II: the ability to claim builds for another user. I can see some value in I - however it has still to be discussed how the 'other' builds are defined. IMHO they should be at least be related in some kind to the current build. E.g. have an up/downstream relationship and/or use the same SCM change I'm still very sceptical about II. I cannot see any good reason why the other user shouldn't be able to claim the build for himself.

          Ankur Goyal added a comment -

          Oh there is a slight misinterpretation with the second point. let me rephrase the II again :-

          "the ability to claim builds OF other users for himself"

          This feature is not for a user to claim the build for someone's behalf.

          Let me explain with an example what this feature does:-

          Lets say we have 2 developers. Dev1 and Dev2. Builds: B1, B2 have Dev1 as culprit and Builds: B3, B4 have Dev2 as culprit. B5 have both dev1 and dev2 as culprit.
          Now, dev1 knows that he can fix B1 B2 along with B5. Also dev2 is not sure if he will be able to fix B3 and asks dev1 (his teammate) to fix it. Therefore:-
          1. dev2 claims B4 for himself with no problem as he can just go to the build and claim it.
          2. dev1 has to claim B1, B2, B3 and B5. (Poor guy). WIth original claim, he would have to go to each and every build and claim them. But with this feature, he can just go to any of the builds say B1, Give a common reason, then from the drop down menu selects "dev1" as culprit. This will display the latest builds failed by dev1 as a checklist ie. B1, B2 and B5 (Not B3 and B4). So he can check them. Now, in order to claim the build B3 of dev2 he then selects "dev2" from drop down menu which will display B3, B4 and B5 as latest failed builds. He will select the one he was asked to fix ie. B3. So dev1 has B2, B3 and B5 checked with the current build B1 (even if not checked) which all get claimed after clicking on claim button as "dev1" as the name of the claimer.

          I hope this explains. Playing around with this feature with different scenarios may help explain better. I can give a small demo on this if anyone wants?

          Just pasting what was explained the scenarios on the github for reference:

          "This feature is based on a scenario that if multiple developers made a commit which not only made his build fail or unstable but also linked to the same project is another project which gets triggered to build after this build and fails due to the upstream build or his commit causes some other job with different configuration fail as well. Now in a big project environment, it may go unnoticed and the person (owner of the downstream project) who was not responsible will be wondering why this happened as the commit changes wont happen on this one but this person will be shown as the culprit. So it makes it easier for the current logged in user to check what other projects (related or not related ones) have failed and claim them in one go. He doesn't need to keep going to individual builds again and again to claim them but instead can do it from one failed build and claim all rest of them from the same page.

          Also, another scenario is, if I know how to fix a broken build which was not broken by me but someone else, I can simply go to one of the failed builds, check the other projects' builds of this "someone" as culprit selected from drop down and claim them all at once."

          Ankur Goyal added a comment - Oh there is a slight misinterpretation with the second point. let me rephrase the II again :- "the ability to claim builds OF other users for himself" This feature is not for a user to claim the build for someone's behalf. Let me explain with an example what this feature does:- Lets say we have 2 developers. Dev1 and Dev2. Builds: B1, B2 have Dev1 as culprit and Builds: B3, B4 have Dev2 as culprit. B5 have both dev1 and dev2 as culprit. Now, dev1 knows that he can fix B1 B2 along with B5. Also dev2 is not sure if he will be able to fix B3 and asks dev1 (his teammate) to fix it. Therefore:- 1. dev2 claims B4 for himself with no problem as he can just go to the build and claim it. 2. dev1 has to claim B1, B2, B3 and B5. (Poor guy). WIth original claim, he would have to go to each and every build and claim them. But with this feature, he can just go to any of the builds say B1, Give a common reason, then from the drop down menu selects "dev1" as culprit. This will display the latest builds failed by dev1 as a checklist ie. B1, B2 and B5 (Not B3 and B4). So he can check them. Now, in order to claim the build B3 of dev2 he then selects "dev2" from drop down menu which will display B3, B4 and B5 as latest failed builds. He will select the one he was asked to fix ie. B3. So dev1 has B2, B3 and B5 checked with the current build B1 (even if not checked) which all get claimed after clicking on claim button as "dev1" as the name of the claimer. I hope this explains. Playing around with this feature with different scenarios may help explain better. I can give a small demo on this if anyone wants? Just pasting what was explained the scenarios on the github for reference: "This feature is based on a scenario that if multiple developers made a commit which not only made his build fail or unstable but also linked to the same project is another project which gets triggered to build after this build and fails due to the upstream build or his commit causes some other job with different configuration fail as well. Now in a big project environment, it may go unnoticed and the person (owner of the downstream project) who was not responsible will be wondering why this happened as the commit changes wont happen on this one but this person will be shown as the culprit. So it makes it easier for the current logged in user to check what other projects (related or not related ones) have failed and claim them in one go. He doesn't need to keep going to individual builds again and again to claim them but instead can do it from one failed build and claim all rest of them from the same page. Also, another scenario is, if I know how to fix a broken build which was not broken by me but someone else, I can simply go to one of the failed builds, check the other projects' builds of this "someone" as culprit selected from drop down and claim them all at once."

          Markus added a comment -

          A work-around to claiming multiple builds could be to do a post from for example curl. I've tried that but I get a 400 error and "This page expects a form submission"

          curl -n 'http://jenkins:8080/job/TestClaiming/lastFailedBuild/claim/claim' --data "reason=testing&sticky=on&Submit=Claim"
          

          Any idea suggestion on how to post the correct data?

          Markus added a comment - A work-around to claiming multiple builds could be to do a post from for example curl. I've tried that but I get a 400 error and "This page expects a form submission" curl -n 'http://jenkins:8080/job/TestClaiming/lastFailedBuild/claim/claim' --data "reason=testing&sticky=on&Submit=Claim" Any idea suggestion on how to post the correct data?

          Andy Pham added a comment -

          Will we also be able to claim multiple test failures once this JIRA is implemented?

          It seems like this couldn't be done with the latest version (1.582). It's a very common scenario where multiple test failures have the same culprit.

          Andy Pham added a comment - Will we also be able to claim multiple test failures once this JIRA is implemented? It seems like this couldn't be done with the latest version (1.582). It's a very common scenario where multiple test failures have the same culprit.

            Unassigned Unassigned
            savier447 Ankur Goyal
            Votes:
            2 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated: