Release notes of git 1.9 detailing this change in git-submodule semantics:
https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/1.9.0.txt

Basically, it used to interpret the argument as a long string (similar to ssh), and letting bash separate the command and arguments. And it now does this at the git level.

Created attachment 16642
git submodule with GIT_TRACE=1

I found that bug while testing a job for pywikibot/core.git which needs to be run on Trusty (it uses python3.4 which is not on Precise). It yielded:

/usr/lib/git-core/git-submodule: 552: /usr/lib/git-core/git-submodule: git reset: not found

I have added to the job a parameter GIT_TRACE=1 and ran it again (see attached console output for https://integration.wikimedia.org/ci/job/pywikibot-core-tox-nose34-trusty/9/console ). The git command shown:

stderr: trace: exec: 'git-submodule' 'foreach' '--recursive' 'git reset' '--hard'

Note how git reset is enclosed in quote. Since git version 1.9.0, that is passed as a single argument to git-submodule which can find such executable 'git reset'.

I eventually had an audio call and had to be back home. The Jenkins git-client-plugin needs to be patched to split 'git reset' to be two args, then compiled via maven and uploaded to Jenkins.

You can take backup of the existing version by looking on gallium under /var/lib/jenkins/plugins/ for some .jpi files.

Note: last time I have upgraded the Jenkins git plugin, the whole CI setup went mad :-/ I gave up investigating the java code change and just stuck to the version we currently have.

Attached:

Created attachment 16643
IRC log of a diagnostic on Pywikibot earlier (time is UTC+2)

For what it is worth, attached is an IRC log from earlier today on Pywikibot. That resulted in the previous attachment showing the 'git reset' not found issue.

Attached:

(In reply to Krinkle from comment #0)

Jobs running on Ubuntu Trusty for repositories with submodules are currently
broken due to a bug in the Jenkins GIT Plugin.

We use Jenkins GIT Plugin 1.5.0, which uses git-client-plugin 1.0.6:

Actually, we while GIT Plugin requires git-client-plugin v1.0.5, we currently use git-client-plugin v1.4.6

https://github.com/wikimedia/git-client-plugin/commits/git-client-1.4.6%2Bwmf1
https://github.com/wikimedia/git-client-plugin/commit/5d4c940519352a0a38038154f8c9690a7a5dba58#diff-4a13310f7c84a9d6e133def48c0aed5aR558

https://wikitech.wikimedia.org/wiki/Nova_Resource:Integration/Jenkins_Plugin

Deployed the .jpi file to Jenkins.

Thank you Timo!

I testing out with the job that shown the issue yesterday: https://integration.wikimedia.org/ci/job/pywikibot-core-tox-nose34-trusty/

Test case:

• Precise fresh workspace > OK
• Precise, rebuild on existing workspace > OK
• Trusty fresh workspace > OK
• Trusty, rebuild on existing workspace > OK

Apparently this is fixed upstream with: https://github.com/jenkinsci/git-client-plugin/commit/f75720d5de9d79ab4be2633a21de23b3ccbf8ce3 which was shipped with version 1.6.4

-        args.add("git reset");
-        if (hard) {
-            args.add("--hard");
-        }
+        args.add("git reset" + (hard ? " --hard" : ""));

Thus the whole command is passed as a single string.

Will switch from our fork/patched version to upstream one as part of T100655

Plugin bumped to upstream 1.7.1