DEV Community

Cover image for Automate Perl module testing with GitHub Actions
DragosTrif
DragosTrif

Posted on

Automate Perl module testing with GitHub Actions

#githubactions #perl #testing

Table of Contents

  1. Introduction
  2. Getting Started with GitHub Actions
  3. Creating the GitHub Actions Workflow
  4. Conclusion

1. Introduction

A while ago, I started working on DBD::Mock::Session::GenerateFixtures, a Perl module that captures the state of a database and stores it as JSON fixtures. These fixtures can later be replayed, allowing database-dependent tests to run without requiring a live database.

Following the Perl community often says, "Test, test, and test some more." As the project evolved, it quickly accumulated a reasonably comprehensive test suite. Running these tests manually after every change soon became repetitive, making Continuous Integration (CI) an obvious next step.

GitHub Actions provides an easy way to automate this process by running the test suite whenever changes are pushed to the repository or a pull request is opened.

2. Getting Started with GitHub Actions

GitHub Actions is GitHub's built-in Continuous Integration and Continuous Deployment (CI/CD) platform. It allows developers to automate tasks such as building software, running tests, publishing releases, or deploying applications.

In this project, the workflow's only responsibility is to build the Perl module and execute its test suite automatically. This ensures that every code change is verified before it is merged into the main branch.

3. Creating the GitHub Actions Workflow

The first step is to create a workflow file named .github/workflows/perl-tests.yml with the following contents:

name: CI

on:
  push:
  pull_request:

jobs:
  perl-job:
    strategy:
      fail-fast: false
      matrix:
        runner:
          - ubuntu-latest
        perl:
          - "5.42.0"

    runs-on: ${{ matrix.runner }}
    name: OS ${{ matrix.runner }} Perl ${{ matrix.perl }}

    steps:
      - uses: actions/checkout@v6

      - name: Set up perl
        uses: shogo82148/actions-setup-perl@v1
        with:
          perl-version: ${{ matrix.perl }}

      - name: Install dependencies
        run: |
          sudo apt-get update
          sudo apt-get install -y \
            mysql-server \
            mysql-client \
            libmysqlclient-dev
          curl -L https://cpanmin.us | perl - --sudo App::cpanminus
          cpanm File::Which
          cpanm --notest --installdeps .

      - name: Run Tests on Linux
        run: |
          perl Makefile.PL
          make
          make test
Enter fullscreen mode Exit fullscreen mode

Let's examine each section of the workflow.

Triggering the Workflow 

on:
  push:
  pull_request:
Enter fullscreen mode Exit fullscreen mode

The on section specifies when the workflow should run. In this case, GitHub automatically starts the workflow whenever code is pushed to the repository or a pull request is opened or updated.

Using a Matrix Strategy 

strategy:
  fail-fast: false
  matrix:
    runner:
      - ubuntu-latest
    perl:
      - "5.42.0"
Enter fullscreen mode Exit fullscreen mode

The matrix strategy allows the same job to run with different combinations of operating systems and Perl versions.

Although this workflow currently tests only a single configuration—Ubuntu with Perl 5.42.0—it can easily be expanded in the future by adding more operating systems or Perl versions.

The fail-fast: false option instructs GitHub to continue running all matrix jobs even if one of them fails. This is particularly useful when testing multiple configurations, as it provides a complete picture of which environments pass and which fail.

Selecting the Runner 

runs-on: ${{ matrix.runner }}
Enter fullscreen mode Exit fullscreen mode

The runs-on directive specifies the virtual machine on which the workflow executes. Since the matrix contains only ubuntu-latest, GitHub provisions a fresh Ubuntu virtual machine for each workflow run.

Naming the Job 

name: OS ${{ matrix.runner }} Perl ${{ matrix.perl }}
Enter fullscreen mode Exit fullscreen mode

This generates a descriptive job name using the values from the matrix. During execution, the job appears as:

OS ubuntu-latest Perl 5.42.0
Enter fullscreen mode Exit fullscreen mode

Meaningful job names become especially useful when the matrix contains multiple operating systems or Perl versions.

Checking Out the Repository 

- uses: actions/checkout@v6
Enter fullscreen mode Exit fullscreen mode

Each workflow begins with a clean virtual machine. The actions/checkout action downloads the repository contents so the remaining steps have access to the project's source code.

Setting Up Perl 

- name: Set up perl
  uses: shogo82148/actions-setup-perl@v1
  with:
    perl-version: ${{ matrix.perl }}
Enter fullscreen mode Exit fullscreen mode

This step installs the required version of Perl. Using the matrix ensures that the correct Perl interpreter is selected automatically.

Installing Dependencies 

- name: Install dependencies
  run: |
    sudo apt-get update
    sudo apt-get install -y \
      mysql-server \
      mysql-client \
      libmysqlclient-dev
    curl -L https://cpanmin.us | perl - --sudo App::cpanminus
    cpanm File::Which
    cpanm --notest --installdeps .
Enter fullscreen mode Exit fullscreen mode

Before building the project, all required dependencies must be installed.

The workflow first updates Ubuntu's package index and installs the MySQL server, client, and development libraries required by the project.

Next, it installs cpanminus (cpanm), a lightweight CPAN package manager, followed by the File::Which module used during the build process.

Finally,

cpanm --notest --installdeps .
Enter fullscreen mode Exit fullscreen mode

installs all Perl module dependencies declared by the project. The --notest option skips testing those dependencies during installation, reducing the overall execution time.

Building and Testing the Module 

- name: Run Tests on Linux
  run: |
    perl Makefile.PL
    make
    make test
Enter fullscreen mode Exit fullscreen mode

The final step builds and tests the module.

  • perl Makefile.PL generates the project's Makefile.
  • make builds the module.
  • make test executes the project's test suite.

If all tests pass, GitHub marks the workflow as successful. Otherwise, the workflow fails, indicating that a something went wrong.

A successful workflow execution appears similar to the following:

Successful GitHub Actions workflow

4. Conclusion

GitHub Actions makes it straightforward to automate the build and testing of Perl modules without requiring dedicated CI infrastructure. Once the workflow is added to a repository, every push and pull request is automatically validated, helping developers detect regressions early and maintain a stable codebase.

For most open-source Perl projects, adding a simple GitHub Actions workflow is a small investment that provides immediate value by ensuring that every code change is continuously tested.

Top comments (0)