mpersico has asked for the wisdom of the Perl Monks concerning the following question:

I've got a perl 5.32 build being executed by a CI system on a remote box. The log of the build abruptly halts about a third of the way through the tests. Is there any way to not use the test harness or make it spit out more than just foobar..................ok for tests? I don't even get sometest..............nook, so I am hoping that getting more output might lead to more insights. Thank you.

Replies are listed 'Best First'.
Re: How do I make a Perl install NOT use the test harness?
by choroba (Archbishop) on Jan 20, 2021 at 21:42 UTC
    If the tests are run by make test, you can try adding the TEST_VERBOSE=1 parameter to make. It works with make disttest, too.

    map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]
Re: How do I make a Perl install NOT use the test harness?
by syphilis (Bishop) on Jan 20, 2021 at 23:42 UTC
    The log of the build abruptly halts about a third of the way through the tests

    Sounds like you might be hitting an issue (or similar to one) that I strike when I build recent perls (including 5.32.0 and all subsequent releases of 5.33.x) on my Windows 7 machine.
    I've assumed it was something specific to my Windows 7 environment, but I don't know.

    My issue is that the following test scripts hang:
    cpan/IO-Compress/t/100generic-deflate.t
    cpan/IO-Compress/t/105oneshot-deflate.t
    cpan/IPC-Cmd/t/01_IPC-Cmd.t

    If I run those tests outside of the test harness then there's no problem - so, there's no guarantee that running your tests outside of the harness will identify any issue. (Does your log always terminate in the same place ? ... maybe somewhere in the IO-Compress tests ?)
    My solution is to simply replace those hanging test files with files of the same name that do nothing more than exit with an "ok" status.
    Otherwise, I have to kill them using process explorer when they hang, as Control-C will kill the entire 'make test' process.

    I think there's a good chance that choroba's suggestion to use verbosity will identify the file that's hanging, if indeed that's what's happening.
    I think that scripting something that would run all of the tests outside of the harness would be a long, demanding and tedious job

    Cheers,
    Rob
Re: How do I make a Perl install NOT use the test harness?
by bliako (Prior) on Jan 21, 2021 at 00:36 UTC

    Provided you are on a *nix system (I don't know what a CI system is) you can try redirecting the output of the install/tests to a file something like:  runtests &> logfile or better, initiate screen and run the install scripts through that and perhaps put it to the background before reaching the critical point.

    Could it be that some special characters from the tests mess your shell and/or connection - some control sequences?

      Presuming the OP means some sort of "Continuous Integration" system like Jenkins. Jenkins will let you define tasks to be run (such as building a package and/or then running its test suite) "continuously" whenever changes are committed to source control (so that you know fairly quickly if someone's commit broke the build). To do this you usually have some sort of agent process running on a pool of worker machines which runs the task (some sort of shell script, although Jenkins has Java roots so something like ant or maven would also be common). That worker may be running as a different user context (so there's possibly environment or shell issues) or possibly shell / tty related issues.

      The cake is a lie.
      The cake is a lie.
      The cake is a lie.

        Github has CI built-in, called Github Actions. You simply need to put into place a configuration file inside of a .github/workflows/ directory. That's it. Nothing else. You can then review the CI operations by going to the "Actions" tab at your Github repository. I've been using Github Actions for a few weeks now after I got pissed off at Travis and quit using them.

        Here's an example file. Note that I've got test coverage enabled as well, which https://coveralls.io picks up automatically:

        spek@scelia ~/repos/dist-mgr $ cat .github/workflows/github_ci_default +.yml name: CI on: push: branches: [ master ] pull_request: branches: [ master ] workflow_dispatch: jobs: test: runs-on: ${{ matrix.os }} strategy: fail-fast: false matrix: os: ['ubuntu-latest', 'macos-latest', 'windows-latest'] perl: [ '5.32', '5.28', '5.24', '5.18' ] include: - perl: '5.32' os: ubuntu-latest coverage: true name: Perl ${{ matrix.perl }} on ${{ matrix.os }} steps: - uses: actions/checkout@v2 - name: Set up perl uses: shogo82148/actions-setup-perl@v1 with: perl-version: ${{ matrix.perl }} - run: perl -V - run: cpanm ExtUtils::PL2Bat - run: cpanm ExtUtils::MakeMaker - run: cpanm --installdeps . - name: Run tests (no coverage) if: ${{ !matrix.coverage }} run: prove -lv t - name: Run tests (with coverage) if: ${{ matrix.coverage }} env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} run: | cpanm -n Devel::Cover::Report::Coveralls cover -ignore Git.pm$ -test -report Coveralls finish: needs: test runs-on: ubuntu-latest steps: - name: Coveralls Finished uses: coverallsapp/github-action@master with: github-token: ${{ secrets.github_token }} parallel-finished: true

        Here's what it looks like on Github.

        GitLab also has CI built-in, called GitLab CI. You simply need to put into place a configuration file .gitlab-ci.yml in your repo's top directory. That's it. Nothing else. You can then review the CI operations by going to the "CI / CD" tab at your GitLab repository. I've been using GitLab CI for a couple of years now after I got pissed off at Github for being bought by Microsoft and quit using them. :-)

        It doesn't really matter which code management system you use these days, they will either have CI built-in or have a 3rd party CI tightly integrated. It is the way forward and I wholeheartedly commend it to all.


        🦛

        thanks for the info.

Re: How do I make a Perl install NOT use the test harness?
by VinsWorldcom (Prior) on Jan 21, 2021 at 19:26 UTC

    Shot in the dark here, but could it be you're hitting an interactive test that is expecting user input? If so and if it's triggered by the ExtUtils::MakeMaker prompt() sub, you could try setting the PERL_MM_USE_DEFAULT environment variable to TRUE so that it'll bypass the test by selecting the default option.

    This happened to me in the past, I don't recall actually seeing the prompt for input (maybe a flush() thing?), just stopping mid-test, and it hangs there until input or until the CI/CD hits its default timeout.

    Good luck!