A Continuous Integration system (aka CI) can shorten the feedback cycle you get for your code.

Usually it will run your unit-tests, (or whatever you tell it to run) every time you push code to your VCS - Version Control System. (GitHub, GitLab, BitBucket, or even Subversion.) It can run it on multiple versions of Perl on the 3 major Operating Systems.

It can run on every Pull-Request so both your contributor and you will know the offered change does not break the code almost immediately.

You can configure it to run the tests of some of the modules that depend on your code to verify that your changes don't break any of the downstream dependencies. Consider this as integration-tests.

It can go further and run your tests even if you have not made any change to verify that changes in the modules your code depends on did not break your code.

Why do I need a CI if I run my tests before releasing my module to CPAN?

  • It can identify problems much earlier.
  • It will help you ensure that other people can also easily build your project.
  • It can catch issues as simple as forgeting to include a file or relying on some local configuration you long forgot about.

Avialable CI systems

  • GitHub Actions is the integrated CI system GitHub offers.
  • Travis-CI is an independent company offering CI system for GitHub repositories.
  • Appveyor
  • CircleCI
  • Azure Pipelines
  • GitLab Pipelines
  • BitBucket Pipelines

CI for CPAN mini-series

The goal of this mini-series is to get to the point where all the CPAN modules that use GitHub for version control have a CI system configured.

A nice collection of Tips for testing Perl modules via GitHub Actions by Felipe Gasper.

GitLab