bad design for Polling vs Checkout algorithms

This issue is archived. You can view it, but you can't modify it. Learn more

XMLWordPrintable

      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

            Assignee:
            Unassigned
            Reporter:
            Kanstantsin Shautsou
            Archiver:
            Jenkins Service Account

              Created:
              Updated:
              Archived: