-
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