Re: [PATCH] test-lib: try harder to ensure a working jgit

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Tue, May 14 2019, Jonathan Nieder wrote:

> Todd Zullinger wrote:
>
>> The JGIT prereq uses 'type jgit' to determine whether jgit is present.
>> While this should be sufficient, if the jgit found is broken we'll waste
>> time running tests which fail due to no fault of our own.
>>
>> Use 'jgit --version' instead, to catch some badly broken jgit
>> installations.
>>
>> Signed-off-by: Todd Zullinger <tmz@pobox.com>
>> ---
>> I ran into such a broken jgit on Fedora >= 30¹.  This is clearly a
>> problem in the Fedora jgit package which will hopefully be resolved
>> soon.  But it may be good to avoid wasting time debugging tests which
>> fail due to a broken tool outside of our control.
>>
>> ¹ https://bugzilla.redhat.com/1709624
>
> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
>
> It would be nice to describe that bug in the commit message, to save
> readers some head scratching.

FWIW the jgit in Debian testing/unstable is similarly broken right now:

    $ apt policy jgit-cli
    jgit-cli:
      Installed: 3.7.1-6
      Candidate: 3.7.1-6
      Version table:
     *** 3.7.1-6 900
            900 http://ftp.nl.debian.org/debian testing/main amd64 Packages
            800 http://ftp.nl.debian.org/debian unstable/main amd64 Packages
            100 /var/lib/dpkg/status
         3.7.1-4 700
            700 http://ftp.nl.debian.org/debian stable/main amd64 Packages
    $ jgit --version; echo $?
    Error: A JNI error has occurred, please check your installation and try again
    Exception in thread "main" java.lang.NoClassDefFoundError: org/kohsuke/args4j/CmdLineException
            at java.lang.Class.getDeclaredMethods0(Native Method)
            at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
            at java.lang.Class.privateGetMethodRecursive(Class.java:3048)
            at java.lang.Class.getMethod0(Class.java:3018)
            at java.lang.Class.getMethod(Class.java:1784)
            at sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:544)
            at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:526)
    Caused by: java.lang.ClassNotFoundException: org.kohsuke.args4j.CmdLineException
            at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
            at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
            at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
            at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
            ... 7 more
    1

So rather than describe specific bugs on RedHat/Debian maybe just say:

    This guards against cases where jgit is present on the system, but
    will fail to run, e.g. because of some JRE issue, or missing Java
    dependencies. Seeing if it gets far enough to process the
    "--version" argument isn't perfect, but seems to be good enough in
    practice. It's also consistent with how we detect some other
    dependencies, see e.g. the CURL and UNZIP prerequisites.