-
Bug
-
Resolution: Unresolved
-
Blocker
-
None
-
2.4.0/1.18.0
1.609.3
After long time of debugging i found that current polling algorithm works in the next way:
Polling:
- Get from remote repo branchnames + sha1
- compare with existed BuilData from latest build (ONE logic)
- If sha1/branch not found -> trigger build (NO RPA attached)
Checkout:
- Build is running and it calls checkout() step in GITScm
- checkout() calls getBuildRevision that calls DefaultBuildChooser that calls getAdvancedCandidateRevisions() that calls revs = GitUtils.filterTipBranches(revs); (SECOND logic)
- filter tips removes all intermediate branches and they never appears in BuildData
That ends in situations that Polling needs branches, but checkout didn't build them.
I fixed this issue by commenting tips filtering https://github.com/KostyaSha/git-plugin/commit/8336202ee5ec8d5a12caa875aeba27b89ac3af58 this allowed build all branches and Polling now satisfied.
Suggestion:
- Put RPA for triggered build as polling result -> allows ensure that BuildData will get what polling wants
- Use the same logic for checkout and polling -> more or less allows hope that checkout will pick what polling mean
- is blocking
-
JENKINS-39693 Surprising behavior of "catching up" with multiple branches.
-
- Open
-
[JENKINS-30475] bad design for Polling vs Checkout algorithms
Description |
Original:
After long time of debugging i found that current polling algorithm works in the next way: # Get from remote repo branchnames + sha1 # compare with existed BuilData in latest build (ONE logic) # If sha1/branch not found -> trigger build (NO RPA attached) # Build is running and it calls checkout() step in GITScm # checkout() calls getBuildRevision that calls DefaultBuildChooser that calls getAdvancedCandidateRevisions() that calls revs = GitUtils.filterTipBranches(revs); (SECOND logic) # filter tips removes all intermediate branches and they never appears in BuildData That ends in situations that Polling needs branches, but checkout didn't build them. I fixed this issue by commenting tips filtering https://github.com/KostyaSha/git-plugin/commit/8336202ee5ec8d5a12caa875aeba27b89ac3af58 this allowed build all branches and Polling now satisfied. Suggestion: # Put RPA as polling result for triggered build -> allows ensure that BuildData will get what polling wants # Use the same logic for checkout and polling -> more or less allows hope that checkout will pick what polling mean |
New:
After long time of debugging i found that current polling algorithm works in the next way: # Get from remote repo branchnames + sha1 # compare with existed BuilData from latest build (ONE logic) # If sha1/branch not found -> trigger build (NO RPA attached) # Build is running and it calls checkout() step in GITScm # checkout() calls getBuildRevision that calls DefaultBuildChooser that calls getAdvancedCandidateRevisions() that calls revs = GitUtils.filterTipBranches(revs); (SECOND logic) # filter tips removes all intermediate branches and they never appears in BuildData That ends in situations that Polling needs branches, but checkout didn't build them. I fixed this issue by commenting tips filtering https://github.com/KostyaSha/git-plugin/commit/8336202ee5ec8d5a12caa875aeba27b89ac3af58 this allowed build all branches and Polling now satisfied. Suggestion: # Put RPA as polling result for triggered build -> allows ensure that BuildData will get what polling wants # Use the same logic for checkout and polling -> more or less allows hope that checkout will pick what polling mean |
Description |
Original:
After long time of debugging i found that current polling algorithm works in the next way: # Get from remote repo branchnames + sha1 # compare with existed BuilData from latest build (ONE logic) # If sha1/branch not found -> trigger build (NO RPA attached) # Build is running and it calls checkout() step in GITScm # checkout() calls getBuildRevision that calls DefaultBuildChooser that calls getAdvancedCandidateRevisions() that calls revs = GitUtils.filterTipBranches(revs); (SECOND logic) # filter tips removes all intermediate branches and they never appears in BuildData That ends in situations that Polling needs branches, but checkout didn't build them. I fixed this issue by commenting tips filtering https://github.com/KostyaSha/git-plugin/commit/8336202ee5ec8d5a12caa875aeba27b89ac3af58 this allowed build all branches and Polling now satisfied. Suggestion: # Put RPA as polling result for triggered build -> allows ensure that BuildData will get what polling wants # Use the same logic for checkout and polling -> more or less allows hope that checkout will pick what polling mean |
New:
After long time of debugging i found that current polling algorithm works in the next way: Polling: # Get from remote repo branchnames + sha1 # compare with existed BuilData from latest build (ONE logic) # If sha1/branch not found -> trigger build (NO RPA attached) Checkout: # Build is running and it calls checkout() step in GITScm # checkout() calls getBuildRevision that calls DefaultBuildChooser that calls getAdvancedCandidateRevisions() that calls revs = GitUtils.filterTipBranches(revs); (SECOND logic) # filter tips removes all intermediate branches and they never appears in BuildData That ends in situations that Polling needs branches, but checkout didn't build them. I fixed this issue by commenting tips filtering https://github.com/KostyaSha/git-plugin/commit/8336202ee5ec8d5a12caa875aeba27b89ac3af58 this allowed build all branches and Polling now satisfied. Suggestion: # Put RPA as polling result for triggered build -> allows ensure that BuildData will get what polling wants # Use the same logic for checkout and polling -> more or less allows hope that checkout will pick what polling mean |
Description |
Original:
After long time of debugging i found that current polling algorithm works in the next way: Polling: # Get from remote repo branchnames + sha1 # compare with existed BuilData from latest build (ONE logic) # If sha1/branch not found -> trigger build (NO RPA attached) Checkout: # Build is running and it calls checkout() step in GITScm # checkout() calls getBuildRevision that calls DefaultBuildChooser that calls getAdvancedCandidateRevisions() that calls revs = GitUtils.filterTipBranches(revs); (SECOND logic) # filter tips removes all intermediate branches and they never appears in BuildData That ends in situations that Polling needs branches, but checkout didn't build them. I fixed this issue by commenting tips filtering https://github.com/KostyaSha/git-plugin/commit/8336202ee5ec8d5a12caa875aeba27b89ac3af58 this allowed build all branches and Polling now satisfied. Suggestion: # Put RPA as polling result for triggered build -> allows ensure that BuildData will get what polling wants # Use the same logic for checkout and polling -> more or less allows hope that checkout will pick what polling mean |
New:
After long time of debugging i found that current polling algorithm works in the next way: Polling: # Get from remote repo branchnames + sha1 # compare with existed BuilData from latest build (ONE logic) # If sha1/branch not found -> trigger build (NO RPA attached) Checkout: # Build is running and it calls checkout() step in GITScm # checkout() calls getBuildRevision that calls DefaultBuildChooser that calls getAdvancedCandidateRevisions() that calls revs = GitUtils.filterTipBranches(revs); (SECOND logic) # filter tips removes all intermediate branches and they never appears in BuildData That ends in situations that Polling needs branches, but checkout didn't build them. I fixed this issue by commenting tips filtering https://github.com/KostyaSha/git-plugin/commit/8336202ee5ec8d5a12caa875aeba27b89ac3af58 this allowed build all branches and Polling now satisfied. Suggestion: # Put RPA for triggered build as polling result -> allows ensure that BuildData will get what polling wants # Use the same logic for checkout and polling -> more or less allows hope that checkout will pick what polling mean |
Resolution | New: Duplicate [ 3 ] | |
Status | Original: Open [ 1 ] | New: Closed [ 6 ] |
Resolution | Original: Duplicate [ 3 ] | |
Status | Original: Closed [ 6 ] | New: Reopened [ 4 ] |
Assignee | Original: Mark Waite [ markewaite ] |
Comment |
[ Duplicate of |
Comment |
[ Wrong, this issue is latest, Jira didn't response with created 30474 so 30475 was right created and modified. UPD: nullified |
Workflow | Original: JNJira [ 165585 ] | New: JNJira + In-Review [ 186317 ] |
Link | New: This issue is blocking JENKINS-39693 [ JENKINS-39693 ] |