GitHub Actions has made continuous integration seamless. Not because it is a superior product – I am by and far a huge fan of CircleCI – but because of its ease in integration. TravisCI was a huge breakthrough in continuous integration for open source projects. Instead of running a private Jenkins server, you could connect your GitHub repo to TravisCI and start building on each commit. However, both TravisCI, CircleCI, and other continuous integration tools require a multi-step setup. GitHub Actions (for better or worse) bypasses this.

Normally you need to commit your pipeline configuration files – .travis.yml, .circleci/config.yaml, etc. – and then go to that service and turn on builds. Or, vice versa and the service would say, "Great, waiting for that new commit which has your pipeline definition!"

GitHub Actions works. If you make a commit with a workflow, it will just run. If you make a pull request from your fork to another project, it just runs. It runs on your fork, and the upstream once merged. The maintainer doesn't need to do anything. No need to follow up and turn on the integration; it just works. 

To me, as an open source maintainer and contributor, this is huge. I am currently being sponsored by Semper IT to add integration tests to Webform CiviCRM. The development happens on GitHub, and there was no continuous integration setup for testing. So, as I got the test written, I also wrote a GitHub Actions workflow to set up a Drupal + CiviCRM project, install the local Webform CiviCRM module, and run the tests. My fork was running the tests on its own since the upstream did not have the workflow committed. Once merged, the workflow started running – even on that merge commit. All it took was a pull request.

The fact GitHub Actions automatically runs when a workflow is committed was a lifesaver when adding Composer 2 support to a CiviCRM build plugin. I built a Drupal + CiviCRM Composer template that sets up Drupal with CiviCRM and DDEV. I tried running it with Composer 2. Things kind of exploded – as I am sure many of us have experienced as various plugins needed to be updated for version 2 Plugin API changes. The civicrm/composer-downloads-plugin package needed to be updated, and luckily it had existing tests. I created a pull request that satisfied all of the breaking changes that needed to be addressed and added a GitHub Action workflow: https://github.com/civicrm/composer-downloads-plugin/pull/1.  And 🎉 there is now automated testing on the package, and all the maintainers needed to do was merge my pull request.

GitHub Actions is cool in its own ways. CircleCI is still a better product. You cannot complain about the ease of setup and how it lowers the barrier to entry for continuous integration in open source projects.