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.

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
[download]

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.

---

🦛

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.

thanks for the info.