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

git polling fails to detect changes when build uses multiple repos

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • git-plugin
    • None
    • Jenkins 2.107.3 on CentOS 7, git-plugin 3.9.0, the remote git server is Gerrit 2.14.1

      I have a Jenkins pipeline job that is configured to trigger builds by polling scm (git) twice a day.  The pipeline job uses a shared library from one repository, and checks out source from three other repositories.  The polling failed to notice new commits on the last three attempts.  I'm attaching the polling log (with the account name and domain expunged).  In addition to missing the new commits in the gvhd2 repo, there's some odd behavior going on here.  It's polling the repo with the shared library in it once, then polling each of the other three repositories 24 times each.  This job uses refs/heads/stable from the shared library repo, and refs/heads/master from the other three.  Since this is a pipeline, there does not appear to be an option to force the polling to use a workspace, which has been suggested as a workaround for these sorts of issues in the past.

          [JENKINS-51791] git polling fails to detect changes when build uses multiple repos

          Rob Miles added a comment -

          We are experiencing this issue too, it's a major blocker for us.

          Rob Miles added a comment - We are experiencing this issue too, it's a major blocker for us.

          Having the same issue, too, in multirepo setup.

          Aleksi Ahtiainen added a comment - Having the same issue, too, in multirepo setup.

          Jan Pesta added a comment - - edited

          I hit the same issue on Jenkins ver. 2.150.1. For demonstration I can share modified pooling log:

          Started on 17.01.2019 16:18:59
          no polling baseline in d:\JenkinsData\workspace\JOB on slave
          Using strategy: Default
          [poll] Last Built Revision: Revision 00e0...... (refs/remotes/repo1/branch-pomless-build)
           > git --version # timeout=10
          using GIT_ASKPASS to set credentials Build user
          Setting http proxy: .................
           > git ls-remote -h http://scmserver/scm/repo/repo1.git # timeout=10
          Found 14 remote heads on http://scmserver/scm/repo/repo1.git
          Using strategy: Default
          [poll] Last Built Revision: Revision f87e...... (refs/remotes/repo2/branch-pomless-build)
           > git --version # timeout=10
          using GIT_ASKPASS to set credentials Build user
          Setting http proxy: ...................
           > git ls-remote -h http://scmserver/scm/repo/repo2.git # timeout=10
          Found 6 remote heads on http://scmserver/scm/repo/repo2.git
          Using strategy: Default
          [poll] Last Built Revision: Revision f030...... (refs/remotes/repo3/master)
           > git --version # timeout=10
          using GIT_ASKPASS to set credentials Build user
          Setting http proxy: ...................
           > git ls-remote -h http://scmserver/scm/repo/repo3.git # timeout=10
          Found 3 remote heads on http://scmserver/scm/repo/repo3.git
          [poll] Latest remote head revision on refs/heads/master is: f030...... - already built by 22
          no polling baseline in d:\JenkinsData\workspace\JOB on slave
          Done. Took 0,49 sec
          No changes
          

          As you can see pooling detect changes, but ignore them and use only last repo result

          Jan Pesta added a comment - - edited I hit the same issue on Jenkins ver. 2.150.1. For demonstration I can share modified pooling log: Started on 17.01.2019 16:18:59 no polling baseline in d:\JenkinsData\workspace\JOB on slave Using strategy: Default [poll] Last Built Revision: Revision 00e0...... (refs/remotes/repo1/branch-pomless-build) > git --version # timeout=10 using GIT_ASKPASS to set credentials Build user Setting http proxy: ................. > git ls-remote -h http://scmserver/scm/repo/repo1.git # timeout=10 Found 14 remote heads on http://scmserver/scm/repo/repo1.git Using strategy: Default [poll] Last Built Revision: Revision f87e...... (refs/remotes/repo2/branch-pomless-build) > git --version # timeout=10 using GIT_ASKPASS to set credentials Build user Setting http proxy: ................... > git ls-remote -h http://scmserver/scm/repo/repo2.git # timeout=10 Found 6 remote heads on http://scmserver/scm/repo/repo2.git Using strategy: Default [poll] Last Built Revision: Revision f030...... (refs/remotes/repo3/master) > git --version # timeout=10 using GIT_ASKPASS to set credentials Build user Setting http proxy: ................... > git ls-remote -h http://scmserver/scm/repo/repo3.git # timeout=10 Found 3 remote heads on http://scmserver/scm/repo/repo3.git [poll] Latest remote head revision on refs/heads/master is: f030...... - already built by 22 no polling baseline in d:\JenkinsData\workspace\JOB on slave Done. Took 0,49 sec No changes As you can see pooling detect changes, but ignore them and use only last repo result

          andrew lorien added a comment -

          Here too.  I have tried :

          • "Wipe out repository and Force clean"
          • manually delete workspace directory
          • edit <JOB>/builds/<LATEST>/build.xml and remove references to the other directory
          • searching for /cache/git- folder which might contain wrong build information.

          andrew lorien added a comment - Here too.  I have tried : "Wipe out repository and Force clean" manually delete workspace directory edit <JOB>/builds/<LATEST>/build.xml and remove references to the other directory searching for /cache/git- folder which might contain wrong build information.

          Jeff Smick added a comment -

          We're seeing this, too. The polling log seems to indicate that the first repository is the only one used to trigger the build. However, the first repo for us is our shared libraries repo.

          Jeff Smick added a comment - We're seeing this, too. The polling log seems to indicate that the first repository is the only one used to trigger the build. However, the first repo for us is our shared libraries repo.

          Jan Pesta added a comment -

          Hi all,

          I just later find out that pooling is behaving little different according to variable resolutions

          when used this notation for checkout:

          [[name: '*/branchVariable']]
          

          to

          [[name: '*/'+branchVariable]]
          

          In first case, checkout works, becase variable resolution is done properly in checkout, but in case of pooling it is trying to find branch with name branchVariable which is not existing.

          Second case works for checkout and pooling. Hope this help.

          Jan Pesta added a comment - Hi all, I just later find out that pooling is behaving little different according to variable resolutions when used this notation for checkout: [[name: '*/branchVariable']] to [[name: '*/'+branchVariable]] In first case, checkout works, becase variable resolution is done properly in checkout, but in case of pooling it is trying to find branch with name branchVariable which is not existing. Second case works for checkout and pooling. Hope this help.

            Unassigned Unassigned
            euphxenos Andrew Lawrence
            Votes:
            7 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated: