Re^3: How do I make a Perl install NOT use the test harness?

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.

🦛

Comment on Re^3: How do I make a Perl install NOT use the test harness? Download Code

Replies are listed 'Best First'.
Re^4: How do I make a Perl install NOT use the test harness? by stevieb (Canon) on Jan 21, 2021 at 11:23 UTC
LOL nice! :) A few years back before built-in CI systems were widely available, I built my own, Test::BrewBuild. It runs tests across all Perlbrew Perl instances on Unixy type systems, and all berrybrew Perl instances on Windows. A dispatcher running on the system you're working on orders all listening test servers across the network/Internet to run the unit test suite, and then they all send back their results which are aggregated. I still use it for running tests on OSs that Github/Travis etc don't offer, and for final full blown suite runs just prior to CPAN upload, where an external CI platform isn't capable for one reason or another to run my entire suite of developer-only tests.	[reply]

Replies are listed 'Best First'.

Re^4: How do I make a Perl install NOT use the test harness?
by stevieb (Canon) on Jan 21, 2021 at 11:23 UTC

LOL nice! :)

A few years back before built-in CI systems were widely available, I built my own, Test::BrewBuild. It runs tests across all Perlbrew Perl instances on Unixy type systems, and all berrybrew Perl instances on Windows. A dispatcher running on the system you're working on orders all listening test servers across the network/Internet to run the unit test suite, and then they all send back their results which are aggregated.

I still use it for running tests on OSs that Github/Travis etc don't offer, and for final full blown suite runs just prior to CPAN upload, where an external CI platform isn't capable for one reason or another to run my entire suite of developer-only tests.

[reply]