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

2 views
Skip to first unread message

andrew@enospc.com (JIRA)

unread,
Jun 7, 2018, 3:02:02 PM6/7/18
to jenkinsc...@googlegroups.com
Andrew Lawrence created an issue
 
Jenkins / Bug JENKINS-51791
git polling fails to detect changes when build uses multiple repos
Issue Type: Bug Bug
Assignee: Mark Waite
Attachments: badpoll
Components: git-plugin
Created: 2018-06-07 19:01
Environment: Jenkins 2.107.3 on CentOS 7, git-plugin 3.9.0, the remote git server is Gerrit 2.14.1
Priority: Major Major
Reporter: Andrew Lawrence

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.

Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
Atlassian logo

mark.earl.waite@gmail.com (JIRA)

unread,
Jun 7, 2018, 3:14:02 PM6/7/18
to jenkinsc...@googlegroups.com
Mark Waite assigned an issue to Unassigned
Change By: Mark Waite
Assignee: Mark Waite

rmiles@etsy.com (JIRA)

unread,
Aug 31, 2018, 6:45:02 PM8/31/18
to jenkinsc...@googlegroups.com
Rob Miles commented on Bug JENKINS-51791
 
Re: git polling fails to detect changes when build uses multiple repos

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

This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

aleksi.ahtiainen@reaktor.com (JIRA)

unread,
Nov 30, 2018, 3:01:02 AM11/30/18
to jenkinsc...@googlegroups.com

jan.pesta@certicon.cz (JIRA)

unread,
Jan 17, 2019, 11:05:02 AM1/17/19
to jenkinsc...@googlegroups.com

I hit the same issue. 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@certicon.cz (JIRA)

unread,
Jan 18, 2019, 4:11:02 AM1/18/19
to jenkinsc...@googlegroups.com
Jan Pesta edited a comment on Bug JENKINS-51791
I hit the same issue on Jenkins ver . 2.150.1. For demonstration I can share modified pooling log:
{noformat}
{noformat}


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

subscriptions@andrewswebsite.net (JIRA)

unread,
Mar 3, 2019, 9:15:02 PM3/3/19
to jenkinsc...@googlegroups.com

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@squishtech.com (JIRA)

unread,
Jun 6, 2019, 12:48:02 PM6/6/19
to jenkinsc...@googlegroups.com

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@certicon.cz (JIRA)

unread,
Jun 7, 2019, 4:10:07 AM6/7/19
to jenkinsc...@googlegroups.com

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.

Reply all
Reply to author
Forward
0 new messages