Ankur Goyal commented on New Feature JENKINS-16671

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."

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira

--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Reply via email to