We now use GitHub Actions to automatically test and build CGE, in addition to our existing CI with Jenkins.

The main advantage of GitHub Actions for us, from a high-level view, is that they are more friendly to new contributors.

1. They work in every fork (even before you do any pull pequest) automatically.

   Jenkins, OTOH, only processes the main repository and PRs to it. Jenkins doesn’t even know about a fork if you don’t ever make a PR.

2. You will see GitHub Actions execution for each commit, nicely presented in GitHub UI. E.g. if you do PR, and you break compilation with some particular FPC version, you will immediately see which FPC version was broken by this commit (detailed logs are also available).

   This was also true for Jenkins, but the GH Actions results just look immediately more informative, with a breakdown into which job failed. In case of Jenkins, you got short information that a job failed, and you needed access to our Jenkins to see all the details why it failed.

3. Execution of all GH Actions (workflows, that in turn contain jobs) is also publicly visible.

The instructions what to do after each push are in .github/workflows/test-and-pack.yml in repo. This is somewhat equivalent to the Jenkins instructions in Jenkinsfile. You can all see them and propose edits to them.

Our workflow uses the same Docker image as our Jenkins to have the same environment for builds.

We also experimented with setup-lazarus-environment action on plain Ubuntu image — and it worked mighty fine, it was trivial to run a GH Action using FPC/Lazarus on plain Ubuntu without having any custom Docker image. Still, we’d need to extend that “plain Ubuntu” with some tools we need for some automatic CGE tests, and in the end (esp. since as our Docker image is useful for other purposes too, like interactive building and Jenkins) it was easier to just use our Docker image in GH Actions.

To be clear, we still also use our beloved Jenkins, but we’re just exploring an alternative.

• Jenkins still gives us ultimate control over the whole process — configuration on master, ability to setup slaves in any way we like (we right now have Linux, Windows, Raspberry Pi slaves, and will soon resume macOS slave thanks to macStadium). E.g. it’s not a problem to have Windows slave with Delphi 11 Enterprise installled, or Raspberry Pi slave.

• It remains to be seen how much of it is worth “switching over” to GH Actions and how much should remain on Jenkins in the foreseeable future. I know that you can run GH workflows on self-hosted machines, but I suspect with this comes both the trouble and the power inherent in the fact that you maintain these machines, their resources like CPU and disk space, yourself. So for now, at least most GH workflows will be on GH-hosted servers, and we shall see how much this is really problematic to us and how much we enjoy it.

• There’s also a question of “money and control”, unrelated to the technical superiority of this or that solution. GH Actions are free for open-source projects (but the infrastructure is closed and depends on GitHub). Jenkins servers require maintenance (which I usually enjoy) and have a cost (paid by my company Cat-astrophe Games which shares some of the Jenkins infrastructure), OTOH Jenkins remains open-source and under our control forever.

• Well, for now I’m just having fun with more automation tools :), and just experimenting.