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

bad design for Polling vs Checkout algorithms

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Blocker Blocker
    • git-plugin
    • 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:

      1. Get from remote repo branchnames + sha1
      2. compare with existed BuilData from latest build (ONE logic)
      3. If sha1/branch not found -> trigger build (NO RPA attached)

      Checkout:

      1. Build is running and it calls checkout() step in GITScm
      2. checkout() calls getBuildRevision that calls DefaultBuildChooser that calls getAdvancedCandidateRevisions() that calls revs = GitUtils.filterTipBranches(revs); (SECOND logic)
      3. 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:

      1. Put RPA for triggered build as polling result -> allows ensure that BuildData will get what polling wants
      2. Use the same logic for checkout and polling -> more or less allows hope that checkout will pick what polling mean

          [JENKINS-30475] bad design for Polling vs Checkout algorithms

          Kanstantsin Shautsou created issue -
          Kanstantsin Shautsou made changes -
          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
          Kanstantsin Shautsou made changes -
          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
          Kanstantsin Shautsou made changes -
          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
          Mark Waite made changes -
          Resolution New: Duplicate [ 3 ]
          Status Original: Open [ 1 ] New: Closed [ 6 ]
          Kanstantsin Shautsou made changes -
          Resolution Original: Duplicate [ 3 ]
          Status Original: Closed [ 6 ] New: Reopened [ 4 ]
          Mark Waite made changes -
          Assignee Original: Mark Waite [ markewaite ]
          Mark Waite made changes -
          Comment [ Duplicate of JENKINS-30474 ]
          Kanstantsin Shautsou made changes -
          Comment [ Wrong, this issue is latest, Jira didn't response with created 30474 so 30475 was right created and modified.
          UPD: nullified JENKINS-30474 to exclude from search results ]
          R. Tyler Croy made changes -
          Workflow Original: JNJira [ 165585 ] New: JNJira + In-Review [ 186317 ]
          Marek Sotola made changes -
          Link New: This issue is blocking JENKINS-39693 [ JENKINS-39693 ]

            Unassigned Unassigned
            integer Kanstantsin Shautsou
            Votes:
            2 Vote for this issue
            Watchers:
            10 Start watching this issue

              Created:
              Updated: