Fixed in pull-request https://github.com/jenkinsci/git-plugin/pull/309

Hi Jean,

I am having some problems with my CI server too and I am wondering if it is the same problem !
Configuration is the same :

• A basic multi-branch job with a parametrized build with parameter BRANCH_TO_BUILD, default **
• Git SCM with branch specifier "${BRANCH_TO_BUILD}"
• SCM polling enabled

Basically what I would like is for the job to trigger a build on any branch (develop, master, feature/xx) if there is a commit on it. I can also manually build a specific branch

What seems to happen is that Jenkins will only poll changes in the branch I manually build. For example :
• if I build manually /develop, afterward my automatic poll will only track changes in develop http://i.imgur.com/8L5tuTS.png
• if I the trigger on manually build with parameter ** then the automatic poll will correctly track all branches http://i.imgur.com/HgBwRMM.png

I believe this is the same issue (or maybe https://issues.jenkins-ci.org/browse/JENKINS-27349 - all 3 seems related) but please confirm otherwise I will open a dedicated issue

Nicolas

Nicolas - your setup sounds like ours. With Jean's patches, and with our jobs configured to require a workspace for polling, it works as we expect. So I don't think you need a new ticket - you either need to manually build the plugin with Jean's changes or wait for them to be included in a release.

Code changed in jenkins
User: Jean Blanchard
Path:
src/main/java/hudson/plugins/git/GitStatus.java
src/test/java/hudson/plugins/git/GitStatusTest.java
http://jenkins-ci.org/commit/git-plugin/cc2ddb7dd0207401c4515633f5c3704757107199
Log:
JENKINS-27352 Fix commit notification for a parametrized branchspec

When the branchspec is parametrized, and a commit notification is received for
the tracked repository, the polling is always triggered, even if a sha1 was
received.

Also, add some FINE logs to the notifyCommit code.

Compare: https://github.com/jenkinsci/git-plugin/compare/9369a12c7bc4...cc2ddb7dd020

Fix included in git plugin 2.4.0 released 18 July 2015

Using Jenkins LTS version 1.609.2 and git plugin 2.4.0. This fix may break builds when there are some default parameters. When job is triggered by hand, parameters are present. When build is triggered by commit notification, parameters are gone.

After downgrading to git plugin 2.3.5 situation is normal - both triggers have parameters set.

morr can you provide a more specific example so that the case you're describing can be investigated further?

When the job is "triggered by hand", I assume that means that it is launched through the Jenkins job page and the parameters are provided as part of that job. Is that correct?

When "build is triggered by commit notification", I assume that means an external process (curl, wget, etc.) invokes a commitNotify URL (http://your-jenkins/jenkins/commitNotify?more-details). Is that correct? If so, what are the details included in that commitNotify URL?

Yes, it is correct for "triggered by hand". Commit notification comes from Stash Webhook to Jenkins and only parameter there is URL of git repository, e.g. 'http://jenkins:8080/jenkins/git/notifyCommit?url=https://stash-server/scm/project/repo.git'. There is no any option to include any additional parameters from this hook.

We've been using 2.4.0 since it came out, and we have seen a problem identical to what Daniel describes. For us it has been very rare. We've had hundreds of builds triggered by commit notifications (coincidentally, also the Stash hook), and have only had two or three missing parameters. Since for us it has been so infrequent (and also impossible to recreate), not much effort has gone in to tracking it down.

We are still on Jenkins 1.580.1, but we may update to 1.609.2 as early as next week.

We updated to 1.609.2 on 08/25, so we've been running with it about a week. We still have git client 1.18.0 and git 2.4.0, and have not seen an increase in the number of triggered builds missing parameters (in fact, I don't think we've seen any since the upgrade).