-
Improvement
-
Resolution: Fixed
-
Minor
I have had a case where I had multiple jobs in the main/master branch of a multibranch pipeline for the same commit. Some of them had succeeded, some had failed and some had been cancelled. Specifically, the latest two ones had succeeded.
All this was because I had just setted up Jenkins, but potentially it could happen in other situations.
The problem is that later, a job for another branch used a cancelled main branch job as reference. That job didn't have any data, so there was nothing to compare against.
It would be good if git-forensics would look at the multiple alternatives and preferred successful jobs over cancelled/unsuccessful ones.
I guess this can be potentially complicated if its made completely generic; in theory the same commit could have been built 3 years ago once and today three times. But I would argue the latest jobs should have preference. If the latest job in my main branch is broken that's on me, but if I had a temporal problem in job #10 and fixed it in job #11 then I would expect job #11 to be used over job #10.
- is duplicated by
-
-
- Resolved
-
- links to
[JENKINS-66890] Prefer successful/latest builds
Cristian
created issue -
| Summary | Original: Prefer successfull/latest builds | New: Prefer successful/latest builds |
| Link |
New:
This issue is duplicated by |
| Assignee | Original: Ulli Hafner [ drulli ] |
| Labels | New: hacktoberfest help-wanted newbie-friendly |
| Labels | Original: hacktoberfest help-wanted newbie-friendly | New: hacktoberfest help-wanted |
| Assignee | New: Ulli Hafner [ drulli ] |
| Status | Original: Open [ 1 ] | New: In Progress [ 3 ] |
| Remote Link | New: This issue links to "PR #712 (Web Link)" [ 29476 ] |
| Released As | New: https://github.com/jenkinsci/git-forensics-plugin/releases/tag/v2.1.0 | |
| Resolution | New: Fixed [ 1 ] | |
| Status | Original: In Progress [ 3 ] | New: Resolved [ 5 ] |