Bug #118105 for FIX-Parser: perlcritic test may fail

Tue Sep 27 15:09:50 2016 SREZIC [...] cpan.org - Ticket created

Subject:

perlcritic test may fail

Some of my smokers report the following failure (probably only if additional perlcritic policies like Perl::Critic::OTRS are installed): ... # Failed test 'Test::Perl::Critic for "blib/lib/FIX/Parser/FIX44.pm"' # at /usr/perl5.16.3t/lib/site_perl/5.16.3/Test/Perl/Critic.pm line 104. # # Variable, subroutine, and package names have to be in CamelCase at line 8, column 9. (no explanation). (Severity: 5) # Variable, subroutine, and package names have to be in CamelCase at line 9, column 32. (no explanation). (Severity: 5) # Variable, subroutine, and package names have to be in CamelCase at line 12, column 1. (no explanation). (Severity: 5) # Variable, subroutine, and package names have to be in CamelCase at line 13, column 9. (no explanation). (Severity: 5) # Variable, subroutine, and package names have to be in CamelCase at line 13, column 16. (no explanation). (Severity: 5) # Variable, subroutine, and package names have to be in CamelCase at line 14, column 5. (no explanation). (Severity: 5) # Variable, subroutine, and package names have to be in CamelCase at line 14, column 22. (no explanation). (Severity: 5) # Variable, subroutine, and package names have to be in CamelCase at line 15, column 8. (no explanation). (Severity: 5) # Variable, subroutine, and package names have to be in CamelCase at line 17, column 9. (no explanation). (Severity: 5) # Variable, subroutine, and package names have to be in CamelCase at line 18, column 19. (no explanation). (Severity: 5) # Variable, subroutine, and package names have to be in CamelCase at line 18, column 42. (no explanation). (Severity: 5) # Variable, subroutine, and package names have to be in CamelCase at line 19, column 14. (no explanation). (Severity: 5) # Perlsecret risk. Venus at line 19, column 35. Perlsecret detected: %s. (Severity: 5) ... etc. snipped ...

Tue Sep 27 22:48:28 2016 ether [...] cpan.org - Correspondence added

On 2016-09-27 12:09:50, SREZIC wrote: Show quoted text

> Some of my smokers report the following failure (probably only if > additional perlcritic policies like Perl::Critic::OTRS are installed): > > ... > # Failed test 'Test::Perl::Critic for > "blib/lib/FIX/Parser/FIX44.pm"' > # at /usr/perl5.16.3t/lib/site_perl/5.16.3/Test/Perl/Critic.pm line > 104. > # > # Variable, subroutine, and package names have to be in CamelCase at > line 8, column 9. (no explanation). (Severity: 5) > # Variable, subroutine, and package names have to be in CamelCase at > line 9, column 32. (no explanation). (Severity: 5) > # Variable, subroutine, and package names have to be in CamelCase at > line 12, column 1. (no explanation). (Severity: 5) > # Variable, subroutine, and package names have to be in CamelCase at > line 13, column 9. (no explanation). (Severity: 5) > # Variable, subroutine, and package names have to be in CamelCase at > line 13, column 16. (no explanation). (Severity: 5) > # Variable, subroutine, and package names have to be in CamelCase at > line 14, column 5. (no explanation). (Severity: 5) > # Variable, subroutine, and package names have to be in CamelCase at > line 14, column 22. (no explanation). (Severity: 5) > # Variable, subroutine, and package names have to be in CamelCase at > line 15, column 8. (no explanation). (Severity: 5) > # Variable, subroutine, and package names have to be in CamelCase at > line 17, column 9. (no explanation). (Severity: 5) > # Variable, subroutine, and package names have to be in CamelCase at > line 18, column 19. (no explanation). (Severity: 5) > # Variable, subroutine, and package names have to be in CamelCase at > line 18, column 42. (no explanation). (Severity: 5) > # Variable, subroutine, and package names have to be in CamelCase at > line 19, column 14. (no explanation). (Severity: 5) > # Perlsecret risk. Venus at line 19, column 35. Perlsecret > detected: %s. (Severity: 5) > ... etc. snipped ...

While this test failure is indeed an issue that should be corrected, please don't allow pod, critic, coverage or kwalitee tests to run for normal user installs, as they make the installation fail unnecessarily when newer versions of the tester module introduces errors that you cannot anticipate. Also spelling tests are dependent on what dictionaries are installed locally, and critic tests use all plugins that are installed, neither of which can be predicted in advance. Either move these tests to xt/, or guard them with: plan skip_all => "These tests are for authors only!" unless $ENV{AUTHOR_TESTING} or $ENV{RELEASE_TESTING};

Tue Sep 27 22:48:28 2016 The RT System itself - Status changed from 'new' to 'open'

Tue Sep 27 22:55:08 2016 TEAM [...] cpan.org - Correspondence added

On 2016-09-28 03:48:28, ETHER wrote: Show quoted text

> On 2016-09-27 12:09:50, SREZIC wrote:

> > Some of my smokers report the following failure (probably only if > > additional perlcritic policies like Perl::Critic::OTRS are > > installed): > > > > ... > > # Failed test 'Test::Perl::Critic for > > "blib/lib/FIX/Parser/FIX44.pm"' > > # at /usr/perl5.16.3t/lib/site_perl/5.16.3/Test/Perl/Critic.pm line > > 104. > > # > > ... > > line 18, column 42. (no explanation). (Severity: 5) > > # Variable, subroutine, and package names have to be in CamelCase > > at > > line 19, column 14. (no explanation). (Severity: 5) > > # Perlsecret risk. Venus at line 19, column 35. Perlsecret > > detected: %s. (Severity: 5) > > ... etc. snipped ...

> > > While this test failure is indeed an issue that should be corrected, > please don't allow pod, critic, coverage or kwalitee tests to run for > normal user installs, as they make the installation fail unnecessarily > when newer versions of the tester module introduces errors that you > cannot anticipate. Also spelling tests are dependent on what > dictionaries are installed locally, and critic tests use all plugins > that are installed, neither of which can be predicted in advance. > > Either move these tests to xt/, or guard them with: > > plan skip_all => "These tests are for authors only!" unless > $ENV{AUTHOR_TESTING} or $ENV{RELEASE_TESTING};

Thanks Karen - no argument there, we'll be converting these to author tests for the next release. The same issue applies to our other distributions so we'll go through those as well.