-
Bug
-
Resolution: Unresolved
-
Major
Right now, there are several cases where 'git ls-remote' is used by default to check for changes that result in incorrect behavior.
1. Currently, '-h' is passed to ls-remote, which automatically ignores any refs not under refs/heads or refs/tags. If the refspec is set to fetch refs/pull-requests/*/from for example, passing -h will cause that to be ignored (this example comes from Atlassian Stash)
2. The plugin only uses the first result of ls-remote. In the case of branch strings with wildcards, there could be multiple results.
3. If the refspec remaps between the remote and the local, ls-remote isn't suitable to check for changes because the branch might have a different name. For example, if the refspec '+refs/pull-requests/*/from:refs/heads/origin/pr/*' is used with a branch string of 'origin/pr/**', checking the remote for changes to origin/pr/** won't work.
It looks like the plugin is already smart enough to switch over to workspace-based polling in some of these cases if the branch string is specified directly, but we've run into cases where it reverts to using 'git ls-remote' when branch comes from a job parameter.
All of our projects have a BRANCH parameter with a default value that's used to fill in the git plugin's branch field.
In addition, we have two refspecs for normal jobs - the regular all branches one and one to match tags. Pull request jobs point at Atlassian Stash pull requests (+refs/pull-requests/*/from:refs/heads/origin/pr/*).
When Jenkins gets notified to poll for changes, it appears to outright ignore anything that wouldn't be matched by a default refspec - in this case, it won't match tags or pull requests since they aren't present in a standard fetch, despite explicitly setting the refspec. Worse, if both the default refspec and the tags refspec are listed, it won't trigger on any changes, reporting that nothing matches the configured refspec, not even master.
This worked just fine in the prior version of the git plugin (2.2.7). I've reproduced the problem on both Jenkins 1.584 and 1.609.1. I've tried forcing re-clone and forcing polling with a workspace to no effect.
It seems to have something to do with the parameterized branch, as using a concrete branch parameter seemed to make the issue go away.
- links to
Thanks for the report and my apologies that 2.4.0 introduced a regression. I had high hopes to introduce no regressions with that release.
The parameterized branch polling in 2.3.5 (and possibly before) would incorrectly poll the most recently used branch, instead of polling the branch named by the default value of the parameter. In your use case, were you relying on it to poll the most recently used branch?
JENKINS-27352was fixed in 2.4.0 to poll with the default value of the "branch to build" parameter. That fix may also have caused it to ignore the refspec's in the polling.JENKINS-17348,JENKINS-27327, andJENKINS-27351were also fixed in 2.4.0 and might have had an impact.Any chance you'd be willing to construct a JUnit based test case in the code which would show the problem?