Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test suite should support detached .git #13410

Closed
p5pRT opened this issue Nov 10, 2013 · 18 comments
Closed

Test suite should support detached .git #13410

p5pRT opened this issue Nov 10, 2013 · 18 comments

Comments

@p5pRT
Copy link

p5pRT commented Nov 10, 2013

Migrated from rt.perl.org#120505 (status was 'resolved')

Searchable as RT120505$

@p5pRT
Copy link
Author

p5pRT commented Nov 10, 2013

From dennis@kaarsemaker.net

Created by dennis@kaarsemaker.net

This is a bug report for perl from dennis@​kaarsemaker.net,
generated with the help of perlbug 1.39 running under perl 5.14.2.

-----------------------------------------------------------------
In my jenkins replacement, I run all tests with .git outside the work tree,
pointed to by $GIT_DIR. This is fairly common git practice, so let's make the
testsuite support this and run the relevant porting tests that are skipped
without this patch.

Perl Info

Flags:
    category=core
    severity=wishlist

Site configuration information for perl 5.14.2:

Configured by Debian Project at Thu Jul 18 22:08:11 UTC 2013.

Summary of my perl5 (revision 5 version 14 subversion 2) configuration:
   
  Platform:
    osname=linux, osvers=3.2.0-37-generic, archname=i686-linux-gnu-thread-multi-64int
    uname='linux komainu 3.2.0-37-generic #58-ubuntu smp thu jan 24 15:28:10 utc 2013 i686 i686 i686 gnulinux '
    config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Dldflags= -Wl,-Bsymbolic-functions -Wl,-z,relro -Dlddlflags=-shared -Wl,-Bsymbolic-functions -Wl,-z,relro -Dcccdlflags=-fPIC -Darchname=i686-linux-gnu -Dprefix=/usr -Dprivlib=/usr/share/perl/5.14 -Darchlib=/usr/lib/perl/5.14 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.14.2 -Dsitearch=/usr/local/lib/perl/5.14.2 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man/man3 -Duse64bitint -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Ud_ualarm -Uusesfio -Uusenm -Ui_libutil -DDEBUGGING=-g -Doptimize=-O2 -Duseshrplib -Dlibperl=libperl.so.5.14.2 -des'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=define, usemultiplicity=define
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=define, use64bitall=undef, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fstack-protector -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2 -g',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fstack-protector -fno-strict-aliasing -pipe -I/usr/local/include'
    ccversion='', gccversion='4.8.1', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=4, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
    libpth=/usr/local/lib /lib/i386-linux-gnu /lib/../lib /usr/lib/i386-linux-gnu /usr/lib/../lib /lib /usr/lib
    libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt
    perllibs=-ldl -lm -lpthread -lc -lcrypt
    libc=, so=so, useshrplib=true, libperl=libperl.so.5.14.2
    gnulibc_version='2.17'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
    cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib -fstack-protector'

Locally applied patches:
    


@INC for perl 5.14.2:
    /home/dennis/ubot_inst/lib/perl5
    /home/dennis/perl/lib/perl5
    /etc/perl
    /usr/local/lib/perl/5.14.2
    /usr/local/share/perl/5.14.2
    /usr/lib/perl5
    /usr/share/perl5
    /usr/lib/perl/5.14
    /usr/share/perl/5.14
    /usr/local/lib/site_perl
    .


Environment for perl 5.14.2:
    HOME=/home/dennis
    LANG=en_US.UTF-8
    LANGUAGE=en_US
    LC_TIME=nl_NL.utf-8
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/dennis/ubot_inst/bin:/home/dennis/bin:/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/home/dennis/bin:/home/dennis/code/hacks
    PERL5LIB=/home/dennis/ubot_inst/lib/perl5:/home/dennis/perl/lib/perl5:
    PERL_BADLANG (unset)
    SHELL=/bin/bash

@p5pRT
Copy link
Author

p5pRT commented Nov 11, 2013

From @bulk88

On Sun Nov 10 14​:22​:58 2013, dennis@​kaarsemaker.net wrote​:

This is a bug report for perl from dennis@​kaarsemaker.net,
generated with the help of perlbug 1.39 running under perl 5.14.2.

-----------------------------------------------------------------
In my jenkins replacement, I run all tests with .git outside the work
tree,
pointed to by $GIT_DIR. This is fairly common git practice, so let's
make the
testsuite support this and run the relevant porting tests that are
skipped
without this patch.

Wheres the patch?

--
bulk88 ~ bulk88 at hotmail.com

@p5pRT
Copy link
Author

p5pRT commented Nov 11, 2013

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Nov 11, 2013

From dennis.kaarsemaker@booking.com

On zo, 2013-11-10 at 16​:56 -0800, bulk88 via RT wrote​:

On Sun Nov 10 14​:22​:58 2013, dennis@​kaarsemaker.net wrote​:

This is a bug report for perl from dennis@​kaarsemaker.net,
generated with the help of perlbug 1.39 running under perl 5.14.2.

-----------------------------------------------------------------
In my jenkins replacement, I run all tests with .git outside the work
tree,
pointed to by $GIT_DIR. This is fairly common git practice, so let's
make the
testsuite support this and run the relevant porting tests that are
skipped
without this patch.

Wheres the patch?

Here it is. RT wouldn't let me attach it. In fact, it doesn't even let
me *see* the ticket.

@p5pRT
Copy link
Author

p5pRT commented Nov 11, 2013

From dennis.kaarsemaker@booking.com

0001-Make-tests-work-with-detached-git-dir.patch
From 4b6ad52236b340226f9525a1b59d6ca2fdbf932e Mon Sep 17 00:00:00 2001
From: Dennis Kaarsemaker <dennis@kaarsemaker.net>
Date: Sun, 10 Nov 2013 23:17:38 +0100
Subject: [PATCH] Make tests work with detached git dir

In my jenkins replacement, I run all tests with .git outside the work tree,
pointed to by $GIT_DIR. This is fairly common git practice, so let's make the
testsuite support this and run the relevant porting tests that are skipped
without this patch.
---
 Porting/cmpVERSION.pl | 2 +-
 t/test.pl             | 4 ++++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/Porting/cmpVERSION.pl b/Porting/cmpVERSION.pl
index 46f1fef..48fbdbc 100755
--- a/Porting/cmpVERSION.pl
+++ b/Porting/cmpVERSION.pl
@@ -32,7 +32,7 @@ unless (GetOptions('diffs' => \$diffs,
 die "$0: This does not look like a Perl directory\n"
     unless -f "perl.h" && -d "Porting";
 die "$0: 'This is a Perl directory but does not look like Git working directory\n"
-    unless -d ".git";
+    unless (-d ".git" || (exists $ENV{GIT_DIR} && -d $ENV{GIT_DIR}));
 
 my $null = devnull();
 
diff --git a/t/test.pl b/t/test.pl
index 5b1ee18..de35d71 100644
--- a/t/test.pl
+++ b/t/test.pl
@@ -176,6 +176,10 @@ sub find_git_or_skip {
 	    }
 	    $source_dir = $where;
 	}
+    } elsif (exists $ENV{GIT_WORK_TREE}) {
+	$source_dir = $ENV{GIT_WORK_TREE};
+    } elsif (exists $ENV{GIT_DIR}) {
+	$source_dir = '.'
     }
     if ($source_dir) {
 	my $version_string = `git --version`;
-- 
1.8.5-rc0-319-g4c665cc

@p5pRT
Copy link
Author

p5pRT commented Nov 11, 2013

From @hvds

Dennis Kaarsemaker <dennis.kaarsemaker@​booking.com> wrote​:
:In my jenkins replacement, I run all tests with .git outside the work tree,
:pointed to by $GIT_DIR. This is fairly common git practice, so let's make the
:testsuite support this and run the relevant porting tests that are skipped
:without this patch.
[...]
:- unless -d ".git";
:+ unless (-d ".git" || (exists $ENV{GIT_DIR} && -d $ENV{GIT_DIR}));

Hmm, that suggests you use git sometimes, but it doesn't seem like
strong enough evidence that you're using it for perl.

How will you distinguish your case from people that follow this "fairly
common git practice" for their own stuff, but download perl as a tarball?

Hugo

@p5pRT
Copy link
Author

p5pRT commented Nov 11, 2013

From dennis.kaarsemaker@booking.com

On ma, 2013-11-11 at 08​:00 +0000, hv@​crypt.org wrote​:

Dennis Kaarsemaker <dennis.kaarsemaker@​booking.com> wrote​:
:In my jenkins replacement, I run all tests with .git outside the work tree,
:pointed to by $GIT_DIR. This is fairly common git practice, so let's make the
:testsuite support this and run the relevant porting tests that are skipped
:without this patch.
[...]
:- unless -d ".git";
:+ unless (-d ".git" || (exists $ENV{GIT_DIR} && -d $ENV{GIT_DIR}));

Hmm, that suggests you use git sometimes, but it doesn't seem like
strong enough evidence that you're using it for perl.

How will you distinguish your case from people that follow this "fairly
common git practice" for their own stuff, but download perl as a tarball?

Fair point, it is of course possible to set GIT_DIR when not working in
the relevant repository, any git command will then return bogus result,
including the ones from the perl test suite. I'd consider that a form of
PEBKAC though, as it will break everything git-related.

Checking for both $ENV{GIT_DIR} and whether a 'blead' branch exists in
the repository it points to should catch this though, as I don't know of
any other project using 'blead' as a branch.

If that's still not enough, checking git ls-tree output to see if perl.c
exists should make the check as solid as can be.

How far do you think the check should go?
--
Dennis Kaarsemaker, Systems Architect
Booking.com
Herengracht 597, 1017 CE Amsterdam
Tel external +31 (0) 20 715 3409
Tel internal (7207) 3409

@p5pRT
Copy link
Author

p5pRT commented Nov 11, 2013

From @hvds

Dennis Kaarsemaker <dennis.kaarsemaker@​booking.com> wrote​:
:On ma, 2013-11-11 at 08​:00 +0000, hv@​crypt.org wrote​:
:> Dennis Kaarsemaker <dennis.kaarsemaker@​booking.com> wrote​:
:> :In my jenkins replacement, I run all tests with .git outside the work tree,
:> :pointed to by $GIT_DIR. This is fairly common git practice, so let's make the
:> :testsuite support this and run the relevant porting tests that are skipped
:> :without this patch.
:> [...]
:> :- unless -d ".git";
:> :+ unless (-d ".git" || (exists $ENV{GIT_DIR} && -d $ENV{GIT_DIR}));
:>
:> Hmm, that suggests you use git sometimes, but it doesn't seem like
:> strong enough evidence that you're using it for perl.
:>
:> How will you distinguish your case from people that follow this "fairly
:> common git practice" for their own stuff, but download perl as a tarball?
:
:Fair point, it is of course possible to set GIT_DIR when not working in
:the relevant repository, any git command will then return bogus result,
:including the ones from the perl test suite. I'd consider that a form of
:PEBKAC though, as it will break everything git-related.
:
:Checking for both $ENV{GIT_DIR} and whether a 'blead' branch exists in
:the repository it points to should catch this though, as I don't know of
:any other project using 'blead' as a branch.
:
:If that's still not enough, checking git ls-tree output to see if perl.c
:exists should make the check as solid as can be.
:
:How far do you think the check should go?

I'm not sure​: what's the impact of running porting tests on a false
positive? I assume there is a reason we don't run them by default.

If the fact it's a false positive means it will report test fails (which
will then be difficult for the user to diagnose, and impossible for her
to fix) that'd be a bad thing; if it means the tests will take significantly
longer to run that'd also be suboptimal.

If the impact is low enough that it's not worth putting extra checks in,
then that's potentially also an argument for simplifying the logic further
and just running them always.

Alternatively we could run them if $ENV{PERL_PORTER} ...

Hugo

@p5pRT
Copy link
Author

p5pRT commented Nov 11, 2013

From dennis.kaarsemaker@booking.com

On ma, 2013-11-11 at 08​:47 +0000, hv@​crypt.org wrote​:

Dennis Kaarsemaker <dennis.kaarsemaker@​booking.com> wrote​:
:On ma, 2013-11-11 at 08​:00 +0000, hv@​crypt.org wrote​:
:> Dennis Kaarsemaker <dennis.kaarsemaker@​booking.com> wrote​:
:> :In my jenkins replacement, I run all tests with .git outside the work tree,
:> :pointed to by $GIT_DIR. This is fairly common git practice, so let's make the
:> :testsuite support this and run the relevant porting tests that are skipped
:> :without this patch.
:> [...]
:> :- unless -d ".git";
:> :+ unless (-d ".git" || (exists $ENV{GIT_DIR} && -d $ENV{GIT_DIR}));
:>
:> Hmm, that suggests you use git sometimes, but it doesn't seem like
:> strong enough evidence that you're using it for perl.
:>
:> How will you distinguish your case from people that follow this "fairly
:> common git practice" for their own stuff, but download perl as a tarball?
:
:Fair point, it is of course possible to set GIT_DIR when not working in
:the relevant repository, any git command will then return bogus result,
:including the ones from the perl test suite. I'd consider that a form of
:PEBKAC though, as it will break everything git-related.
:
:Checking for both $ENV{GIT_DIR} and whether a 'blead' branch exists in
:the repository it points to should catch this though, as I don't know of
:any other project using 'blead' as a branch.
:
:If that's still not enough, checking git ls-tree output to see if perl.c
:exists should make the check as solid as can be.
:
:How far do you think the check should go?

I'm not sure​: what's the impact of running porting tests on a false
positive? I assume there is a reason we don't run them by default.

That's not what this test is used for. It's used in test_porting to
disable certain tests, it's not a switch to enable porting tests.

If the fact it's a false positive means it will report test fails (which
will then be difficult for the user to diagnose, and impossible for her
to fix) that'd be a bad thing; if it means the tests will take significantly
longer to run that'd also be suboptimal.

If the impact is low enough that it's not worth putting extra checks in,
then that's potentially also an argument for simplifying the logic further
and just running them always.

The impact is that some porting tests get skipped with a pretty clear
error message (they don't fail). With GIT_DIR set to 'nonexistent' this
happens​:

porting/authors.t ......... fatal​: Not a git repository​: 'nonexistent'
porting/cmp_version.t ..... skipped​: Git found, but no Git tags found
porting/manifest.t ........ 9894/? fatal​: Not a git repository​: 'nonexistent'
porting/pending-author.t .. skipped​: No pending changes (or git status --porcelain doesn't work here)
Files=27, Tests=41175, 46 wallclock secs ( 4.21 usr 0.06 sys + 41.74 cusr 1.69 csys = 47.70 CPU)
Result​: PASS

So I think the patch is fine even as-is and no further detection is
needed.
--
Dennis Kaarsemaker, Systems Architect
Booking.com
Herengracht 597, 1017 CE Amsterdam
Tel external +31 (0) 20 715 3409
Tel internal (7207) 3409

@p5pRT
Copy link
Author

p5pRT commented Nov 11, 2013

From @tonycoz

On Mon Nov 11 00​:57​:05 2013, dennis.kaarsemaker@​booking.com wrote​:

On ma, 2013-11-11 at 08​:00 +0000, hv@​crypt.org wrote​:

How will you distinguish your case from people that follow this
"fairly
common git practice" for their own stuff, but download perl as a
tarball?

Fair point, it is of course possible to set GIT_DIR when not working
in
the relevant repository, any git command will then return bogus
result,
including the ones from the perl test suite. I'd consider that a form
of
PEBKAC though, as it will break everything git-related.

Checking for both $ENV{GIT_DIR} and whether a 'blead' branch exists in
the repository it points to should catch this though, as I don't know
of
any other project using 'blead' as a branch.

If that's still not enough, checking git ls-tree output to see if
perl.c
exists should make the check as solid as can be.

Check that a given SHA exists, eg. that​:

git log -n1 a0d0e21ea6ea90a22318550944fe6cb09ae10cdb

for example, succeeds.

I thought we had a test that had been modified to do something similar
to avoid problems in the Debian git repository, but I can't find it and
can't get to the debian gitweb right now[1].

Tony

[1] http​://lists.debian.org/debian-infrastructure-announce/2013/11/msg00001.html

@p5pRT
Copy link
Author

p5pRT commented Nov 11, 2013

From dennis.kaarsemaker@booking.com

On ma, 2013-11-11 at 14​:32 -0800, Tony Cook via RT wrote​:

On Mon Nov 11 00​:57​:05 2013, dennis.kaarsemaker@​booking.com wrote​:

On ma, 2013-11-11 at 08​:00 +0000, hv@​crypt.org wrote​:

How will you distinguish your case from people that follow this
"fairly
common git practice" for their own stuff, but download perl as a
tarball?

Fair point, it is of course possible to set GIT_DIR when not working
in
the relevant repository, any git command will then return bogus
result,
including the ones from the perl test suite. I'd consider that a form
of
PEBKAC though, as it will break everything git-related.

Checking for both $ENV{GIT_DIR} and whether a 'blead' branch exists in
the repository it points to should catch this though, as I don't know
of
any other project using 'blead' as a branch.

If that's still not enough, checking git ls-tree output to see if
perl.c
exists should make the check as solid as can be.

Check that a given SHA exists, eg. that​:

git log -n1 a0d0e21ea6ea90a22318550944fe6cb09ae10cdb

for example, succeeds.

I thought we had a test that had been modified to do something similar
to avoid problems in the Debian git repository, but I can't find it and
can't get to the debian gitweb right now[1].

That's a good idea! Revised patch attached.
--
Dennis Kaarsemaker, Systems Architect
Booking.com
Herengracht 597, 1017 CE Amsterdam
Tel external +31 (0) 20 715 3409
Tel internal (7207) 3409

@p5pRT
Copy link
Author

p5pRT commented Nov 11, 2013

From dennis.kaarsemaker@booking.com

0001-Make-tests-work-with-detached-git-dir.patch
From 77e5f5352bc2b4ce409eccc944c1bece3c3946bc Mon Sep 17 00:00:00 2001
From: Dennis Kaarsemaker <dennis@kaarsemaker.net>
Date: Sun, 10 Nov 2013 23:17:38 +0100
Subject: [PATCH] Make tests work with detached git dir

In my jenkins replacement, I run all tests with .git outside the work tree,
pointed to by $GIT_DIR. This is fairly common git practice, so let's make the
testsuite support this and run the relevant porting tests that are skipped
without this patch.
---
 Porting/cmpVERSION.pl | 2 +-
 t/test.pl             | 5 +++++
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/Porting/cmpVERSION.pl b/Porting/cmpVERSION.pl
index 46f1fef..48fbdbc 100755
--- a/Porting/cmpVERSION.pl
+++ b/Porting/cmpVERSION.pl
@@ -32,7 +32,7 @@ unless (GetOptions('diffs' => \$diffs,
 die "$0: This does not look like a Perl directory\n"
     unless -f "perl.h" && -d "Porting";
 die "$0: 'This is a Perl directory but does not look like Git working directory\n"
-    unless -d ".git";
+    unless (-d ".git" || (exists $ENV{GIT_DIR} && -d $ENV{GIT_DIR}));
 
 my $null = devnull();
 
diff --git a/t/test.pl b/t/test.pl
index 5b1ee18..ccb3ebd 100644
--- a/t/test.pl
+++ b/t/test.pl
@@ -176,6 +176,11 @@ sub find_git_or_skip {
 	    }
 	    $source_dir = $where;
 	}
+    } elsif (exists $ENV{GIT_DIR}) {
+	my $commit = '8d063cd8450e59ea1c611a2f4f5a21059a2804f1';
+	if(`git rev-parse --verify --quiet '$commit^{commit}'` ne $commit) {
+	    $source_dir = '.'
+	}
     }
     if ($source_dir) {
 	my $version_string = `git --version`;
-- 
1.8.5-rc0-319-g4c665cc

@p5pRT
Copy link
Author

p5pRT commented Nov 12, 2013

From @hvds

Dennis Kaarsemaker <dennis.kaarsemaker@​booking.com> wrote​:
:On ma, 2013-11-11 at 14​:32 -0800, Tony Cook via RT wrote​:
:> Check that a given SHA exists, eg. that​:
:>
:> git log -n1 a0d0e21ea6ea90a22318550944fe6cb09ae10cdb
:>
:> for example, succeeds.
[...]
:That's a good idea! Revised patch attached.

Looks good to me.

Hugo

@p5pRT
Copy link
Author

p5pRT commented Dec 4, 2013

From @tonycoz

On Mon Nov 11 15​:20​:51 2013, dennis.kaarsemaker@​booking.com wrote​:

On ma, 2013-11-11 at 14​:32 -0800, Tony Cook via RT wrote​:

On Mon Nov 11 00​:57​:05 2013, dennis.kaarsemaker@​booking.com wrote​:

On ma, 2013-11-11 at 08​:00 +0000, hv@​crypt.org wrote​:

How will you distinguish your case from people that follow this
"fairly
common git practice" for their own stuff, but download perl as a
tarball?

Fair point, it is of course possible to set GIT_DIR when not working
in
the relevant repository, any git command will then return bogus
result,
including the ones from the perl test suite. I'd consider that a form
of
PEBKAC though, as it will break everything git-related.

Checking for both $ENV{GIT_DIR} and whether a 'blead' branch exists in
the repository it points to should catch this though, as I don't know
of
any other project using 'blead' as a branch.

If that's still not enough, checking git ls-tree output to see if
perl.c
exists should make the check as solid as can be.

Check that a given SHA exists, eg. that​:

git log -n1 a0d0e21ea6ea90a22318550944fe6cb09ae10cdb

for example, succeeds.

I thought we had a test that had been modified to do something similar
to avoid problems in the Debian git repository, but I can't find it and
can't get to the debian gitweb right now[1].

That's a good idea! Revised patch attached.

Two porting tests fail for me if I point GIT_DIR at a non-perl git directory​:

$ GIT_DIR=/home/tony/dev/imager/git/Imager/.git make -j3 test_porting
...
Test Summary Report


porting/authors.t (Wstat​: 0 Tests​: 9 Failed​: 6)
  Failed tests​: 1-3, 5, 7-8
porting/manifest.t (Wstat​: 0 Tests​: 10219 Failed​: 5)
  Failed tests​: 10214, 10216-10219
Files=27, Tests=40445, 45 wallclock secs ( 2.99 usr 0.07 sys + 31.63 cusr 1.33 csys = 36.02 CPU)
Result​: FAIL
make​: *** [test_porting] Error 11

I created the clone with​:

  git clone --separate-git-dir=sepperl.git git​://git/perl.git sepperl

(git​://git/perl.git is my local mirror)

Testing with the correct GIT_DIR correctly ran the git dependent tests and passed.

Tony

@p5pRT
Copy link
Author

p5pRT commented Dec 14, 2013

From dennis@kaarsemaker.net

On di, 2013-12-03 at 21​:18 -0800, Tony Cook via RT wrote​:

On Mon Nov 11 15​:20​:51 2013, dennis.kaarsemaker@​booking.com wrote​:

On ma, 2013-11-11 at 14​:32 -0800, Tony Cook via RT wrote​:

On Mon Nov 11 00​:57​:05 2013, dennis.kaarsemaker@​booking.com wrote​:

On ma, 2013-11-11 at 08​:00 +0000, hv@​crypt.org wrote​:

How will you distinguish your case from people that follow this
"fairly
common git practice" for their own stuff, but download perl as a
tarball?

Fair point, it is of course possible to set GIT_DIR when not working
in
the relevant repository, any git command will then return bogus
result,
including the ones from the perl test suite. I'd consider that a form
of
PEBKAC though, as it will break everything git-related.

Checking for both $ENV{GIT_DIR} and whether a 'blead' branch exists in
the repository it points to should catch this though, as I don't know
of
any other project using 'blead' as a branch.

If that's still not enough, checking git ls-tree output to see if
perl.c
exists should make the check as solid as can be.

Check that a given SHA exists, eg. that​:

git log -n1 a0d0e21ea6ea90a22318550944fe6cb09ae10cdb

for example, succeeds.

I thought we had a test that had been modified to do something similar
to avoid problems in the Debian git repository, but I can't find it and
can't get to the debian gitweb right now[1].

That's a good idea! Revised patch attached.

Two porting tests fail for me if I point GIT_DIR at a non-perl git directory​:

$ GIT_DIR=/home/tony/dev/imager/git/Imager/.git make -j3 test_porting
...
Test Summary Report
-------------------
porting/authors.t (Wstat​: 0 Tests​: 9 Failed​: 6)
Failed tests​: 1-3, 5, 7-8
porting/manifest.t (Wstat​: 0 Tests​: 10219 Failed​: 5)
Failed tests​: 10214, 10216-10219
Files=27, Tests=40445, 45 wallclock secs ( 2.99 usr 0.07 sys + 31.63 cusr 1.33 csys = 36.02 CPU)
Result​: FAIL
make​: *** [test_porting] Error 11

I created the clone with​:

git clone --separate-git-dir=sepperl.git git​://git/perl.git sepperl

(git​://git/perl.git is my local mirror)

Testing with the correct GIT_DIR correctly ran the git dependent tests and passed.

This version should do that correctly. There's now only one situation
that doesn't work (by design, according to existing comments in
test.pl)​: having a .git in your clone, but pointing GIT_DIR elsewhere,
to a non-perl git repo.

--
Dennis Kaarsemaker
www.kaarsemaker.net

@p5pRT
Copy link
Author

p5pRT commented Dec 14, 2013

From dennis@kaarsemaker.net

0001-Make-tests-work-with-detached-git-dir.patch
From 9d0a665e620cc3dff2470eaec6ca972ffe070479 Mon Sep 17 00:00:00 2001
From: Dennis Kaarsemaker <dennis@kaarsemaker.net>
Date: Sun, 10 Nov 2013 23:17:38 +0100
Subject: [PATCH] Make tests work with detached git dir

In my jenkins replacement, I run all tests with .git outside the work tree,
pointed to by $GIT_DIR. This is fairly common git practice, so let's make the
testsuite support this and run the relevant porting tests that are skipped
without this patch.
---
 Porting/cmpVERSION.pl | 2 +-
 t/test.pl             | 7 +++++++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/Porting/cmpVERSION.pl b/Porting/cmpVERSION.pl
index 46f1fef..48fbdbc 100755
--- a/Porting/cmpVERSION.pl
+++ b/Porting/cmpVERSION.pl
@@ -32,7 +32,7 @@ unless (GetOptions('diffs' => \$diffs,
 die "$0: This does not look like a Perl directory\n"
     unless -f "perl.h" && -d "Porting";
 die "$0: 'This is a Perl directory but does not look like Git working directory\n"
-    unless -d ".git";
+    unless (-d ".git" || (exists $ENV{GIT_DIR} && -d $ENV{GIT_DIR}));
 
 my $null = devnull();
 
diff --git a/t/test.pl b/t/test.pl
index 5b1ee18..fcab07a 100644
--- a/t/test.pl
+++ b/t/test.pl
@@ -176,6 +176,13 @@ sub find_git_or_skip {
 	    }
 	    $source_dir = $where;
 	}
+    } elsif (exists $ENV{GIT_DIR}) {
+	my $commit = '8d063cd8450e59ea1c611a2f4f5a21059a2804f1';
+	my $out = `git rev-parse --verify --quiet '$commit^{commit}'`;
+	chomp $out;
+	if($out eq $commit) {
+	    $source_dir = '.'
+	}
     }
     if ($source_dir) {
 	my $version_string = `git --version`;
-- 
1.8.5-386-gb78cb96

@p5pRT
Copy link
Author

p5pRT commented Dec 16, 2013

From @tonycoz

On Sat Dec 14 14​:54​:40 2013, dennis@​kaarsemaker.net wrote​:

This version should do that correctly. There's now only one situation
that doesn't work (by design, according to existing comments in
test.pl)​: having a .git in your clone, but pointing GIT_DIR elsewhere,
to a non-perl git repo.

Thanks, applied as 6b44ec6.

Tony

@p5pRT p5pRT closed this as completed Dec 16, 2013
@p5pRT
Copy link
Author

p5pRT commented Dec 16, 2013

@tonycoz - Status changed from 'open' to 'resolved'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant