It would be great to confirm that the problem also occurs when using a commitNotify from something other than Stash. I don't have a Stash installation available, so it will help if I can see it from commitNotify from a simple bare git repository, rather than requiring Stash.

The actual commit notification from Stash (taken from logs) looks like this:

GET /git/notifyCommit?url=ssh%3A%2F%2Fgit%40stash.example.com%3A1234%2Fproj%2Frepo.git&branches=branch&sha1=0123456789abcdef0123456789abcdef01234567

In the newest versions of Stash you can also:

• Omit SHA1 Hash Code
• Omit Branch Name

(these options are disabled by default)

HTH.

If a sha1 is provided, the build is triggered without default parameters:
https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitStatus.java#L281...L292

buildParameters in the above code seems to be fed in
https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitStatus.java#L72
which means it only contains explicitly passed parameters, and not those defined in the job.

Haven't confirmed in a debugger, but seems to explain what's going on here.

Additionally, if there are no such parameters, the build will end up with an empty ParametersAction in the sidepanel anyway. This should really only be set when there actually are parameters IMO.

Part of a general lack of coherent handling of default parameters in Jenkins core.

In my tests with git plugin 2.4.0 and git client plugin 1.19.0, I can only duplicate the problem if I include "sha1=" in the notify commit argument list (just as Daniel Beck observed in an earlier comment). When I include no argument, and when I include only the argument "branch=", then the default parameter values are visible to the XShell and Shell build steps in my test job.

The notify commit I used to show the problem was:

SHA1=$(git rev-parse HEAD)
curl -s http://localhost:8080/git/notifyCommit?url=git://mark-pc1.markwaite.net/git/mwaite/bugs/JENKINS-30178.git\&branch=master\&sha1=$SHA1

The notify commit I used that does not show the problem is:

curl -s http://localhost:8080/git/notifyCommit?url=git://mark-pc1.markwaite.net/git/mwaite/bugs/JENKINS-30178.git\&branch=master

danielbeck claims in the PR for JENKINS-27902 that it caused this.

Code changed in jenkins
User: Mark Waite
Path:
src/main/java/hudson/plugins/git/GitStatus.java
src/test/java/hudson/plugins/git/GitStatusTest.java
http://jenkins-ci.org/commit/git-plugin/2dfd86d27a7cd4089349fd012d7d70a5e827ed81
Log:
Test JENKINS-30178 using GitStatus.toString

Asserts that job parameter default values are available when a job
is started by a notifyCommit. If the notifyCommit includes a sha1
parameter, then the changes for JENKINS-27092 fail to assign parameters
their default values.

Modifying the GitStatus object to be more easily tested was simpler
than using a TestExtension. Should eventually replace the testing
misuse of the GitStatus.toString() method with a TestExtension of
GitStatus.Listener.

Code changed in jenkins
User: fbelzunc
Path:
src/main/java/hudson/plugins/git/GitStatus.java
http://jenkins-ci.org/commit/git-plugin/0a661ceaa5da94e92df97a2220a792d1eaa34317
Log:
[Fix JENKINS-30178] Add default parameters defined in the job

I can confirm that this problem is resolved after upgrading git plugin to 2.4.1 and git-client plugin to 1.19.1. This issue can be closed. Thank you very much for your work, guys.