Bug when cpanm reports string missmatches between phases about app-cpanminus-reporter HOT 10 CLOSED

As a temporary fix, I've locally modified this line

-      elsif ( $dist and /^Building and testing $dist/) {
+     elsif ( $dist and /^Building and testing (\S+)/) {

Which gets around the no-report issue for me.

I just don't know how reliable that is long-term

from app-cpanminus-reporter.

Here's another one that looks to be caused by the same root issue: http://www.cpantesters.org/cpan/report/7fecbb8e-a7df-11e3-a8dc-2015ec1cabe9

from app-cpanminus-reporter.

Hi guys!

@kentfredric 19744be should fix this issue. Could you please check?
@karenetheridge I don't understand... what's wrong with the report you linked?

from app-cpanminus-reporter.

A quick glance says it should solve the /specific/ case above with the vstring. However, I doubt it will solve the generic case, which is that the metadata inside META.json can differ from the name of the tar.gz

Which means I think its quite legal to do:

    foo-bar.tar.gz : {
           'name': 'quux',
           'version': '1.500',
    }

Or similar.

And cpanm reports the string on the tar before it extracts it to get the metadata which gives it the name and version values.

Contrived I know, but there are probably examples.

from app-cpanminus-reporter.

I see. Well, in that case I'm gonna make it more like your original patch. The reason I didn't was mainly because parsing build output text is very fragile, so I wanted to be as close to the example at hand as possible and double check data (like the dist name) whenever possible to avoid runaway logs.

That said, I'm fairly confident the 'Building and testing' string only occurs on cpanm for the innermost dist being installed, so it's safe to process the line without checking the dist name.

I'll add more tests anyway :)

from app-cpanminus-reporter.

I think the thing to lookout for with my change, is the case ether presented, which I believe was caused by my change.

ie: Its reporting HTML-FormHandler to the MooseX-Getopt test report queue

My suspicion is MooseX::Getopt failed somewhere before running HTML::FormHandler

Or some expected line wasn't emitted, which made it think $dist was still MooseX::Getopt... but how that is I don't know.

from app-cpanminus-reporter.

Ok, I've found one example case that really makes cpanm_reporter get confused:

https://metacpan.org/release/PLOCKABY/v1.0.0

$ cpan http://cpan.metacpan.org/authors/id/P/PL/PLOCKABY/v1.0.0.tar.gz
--> Working on http://cpan.metacpan.org/authors/id/P/PL/PLOCKABY/v1.0.0.tar.gz
--> Working on http://cpan.metacpan.org/authors/id/P/PL/PLOCKABY/v1.0.0.tar.gz
Fetching http://cpan.metacpan.org/authors/id/P/PL/PLOCKABY/v1.0.0.tar.gz
Fetching http://cpan.metacpan.org/authors/id/P/PL/PLOCKABY/v1.0.0.tar.gz ... OK
-> OK
Fetching http://cpan.metacpan.org/authors/id/P/PL/PLOCKABY/CHECKSUMS
Fetching http://cpan.metacpan.org/authors/id/P/PL/PLOCKABY/CHECKSUMS ... OK
-> OK
Verifying the signature of CHECKSUMS
random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
              outmix=0 getlvl1=0/0 getlvl2=0/0
secmem usage: 0/32768 bytes in 0 blocks
Verified OK!
Verifying the SHA1 for v1.0.0.tar.gz
Checksum for v1.0.0.tar.gz: Verified!
Unpacking v1.0.0.tar.gz
Entering perl-thread-queue-priority-1.0.0
Checking configure dependencies from META.json
Checking if you have ExtUtils::MakeMaker 0 ... Yes (6.90)
Configuring Thread-Queue-Priority-v1.0.0
Running Makefile.PL
Configuring Thread-Queue-Priority-v1.0.0 ... Generating a Unix-style Makefile
Writing Makefile for Thread::Queue::Priority
Writing MYMETA.yml and MYMETA.json
OK
-> OK
Checking dependencies from MYMETA.json ...
Checking if you have ExtUtils::MakeMaker 0 ... Yes (6.90)
Checking if you have Scalar::Util 1.1 ... Yes (1.38)
Checking if you have threads::shared 1.21 ... Yes (1.46)
Checking if you have Test::More 0.5 ... Yes (1.001002)
Building and testing Thread-Queue-Priority-v1.0.0

Yes:

1. tarball name doesn't match $distname-$version at all
2. extracted path doesn't match ^$distname-$version, but instead, perl-$distname-$version
3. configure produces a 3rd string not seen in either 1 or 2

cpanm-reporter doesn't even see this test and just skips over it, producing not even error messages =)

from app-cpanminus-reporter.

@garu what's wrong with the report I linked is it was sent to me labelled as a report for MooseX-Getopt, but the build and test output is all HTML-FormHandler.

from app-cpanminus-reporter.

..but now I see that @kentfredric covered that.

from app-cpanminus-reporter.

I am pretty confident this was fixed but we forgot to close it, so I'm going to do it and if the error happens again with cpanm-reporter 0.19 please let me know and we'll work on it.
Thanks!

from app-cpanminus-reporter.