The git plugin and git client plugin are being tested in hopes of releasing new versions before the end of June. If you're willing to assist with the testing, please download and install a pre-release build of the git client plugin and the git plugin. Problems detected in the pre-release should be e-mailed to MarkEWaite and ndeloof.

I wrote some test ideas if you would like suggestions of areas that need testing. The git plugin supports many different use cases and its automated tests only evaluate a very few of those use cases.

Is there any way this pre-release could be updated to include the fix for JENKINS-27352? I installed the pre-release last week, but had to back it out. We're back to running a patched version that includes all of Jean's fixes.

I attempted to apply just the test from the pull request. I needed to resolve some merge conflicts, and still need to more deeply read and understand the code before it can be accepted into the master branch.

If I provide you a custom build which includes that change and the rest of the current 2.3.6 changes, would you help test it?

If you provide me directly with the built plugin (don't know how to do it from sources, I admit I never looked at it) I can help test #27352 ans this one

A build of the git plugin which includes the latest changes of the 2.3.6 pre-release and pull request 309 is available.

That build does not include pull request 308

Thanks Mark. 308 doesn't look too dangerous, but we default our parameter to '**' instead of leaving it blank, so I believe we'll work fine without it. I'll give your new build a try.

So far so good. We do a lot of builds per day, so I consider this tested for our use cases. Our git config across jobs is pretty homogeneous, though, so I can't claim all features of the plugin have been tested (I'm sure there are plenty we don't use). Thanks again for the new build.

Thanks for the test results. Very much appreciated!

I ran som test too and so far the behavior is correct

I ran some verification tests switching between 2.3.5 (buggy) and the next pre-release. It was well behaved in all the cases I tested.

0. Create a bare git repository /var/lib/git/mwaite/bugs/JENKINS-27349.git
0. Commit a master branch to that repository
0. Commit a branch named "default-branch" to that repository
1. Create a freestyle job, "JENKINS-27349"
2. Add string parameter BRANCH_TO_BUILD with "default-branch" as default
3. Define git repository to use the bare repository
4. Build the job with BRANCH_TO_BUILD "master"
1. Confirm the master branch built as expected
5. Commit a change to the default-branch
6. Use the "poll now" button to poll the repository for that job
1. Confirm that the build did not happen even though there was a
change on default-branch which the poll should have detected (bug)
7. Configure a post-receive hook on the repository
8. Commit a change to the default-branch
1. Confirm that the job polled
2. Confirm that the poll did not trigger the default-branch even
though that is the default value (bug)