Github announced Github Actions earlier this year, with a fairly broad scope of CI/CD tasks, as well as a general “action platform” for actioning Github events. The scope seems to include running tests/builds in a similar way to TravisCI and CircleCI. Given we’re using lots of other Github tooling, it’s worth assessing this potential alternative.
I’m not suggesting that we make the switch, so this isn’t an RFC (yet), just an early stage place to centralise discussion. This was triggered by the current discussion on RFC: Unify Travis Config.
- Usage Limits: Github Actions gives us 20 concurrent jobs free, each with max. 6 hours exec time (see usage limits). Compare to an undefined amount of concurrent jobs on Travis, although there’s some old Tweets saying it’s 5 concurrent jobs. 120 minutes exec time on Travis. In Dec, we averaged 30 public builds per day between travis-ci.com and travis-ci.org, with an average queue time of 16 mins. So we could benefit from higher concurrency
- Software coverage on Github runners seems to work for us? Unlike Travis, they don’t have PHP 7.4 preview or stable in there, so it might limit our testing on future pre-release PHP versions
- Would need to rebuild our team dashboard
- The build matrix looks pretty similar to Travis, they have env vars
- They also cache across builds (npm, composer)
- Static build matrix (through jobs definitions)
- Self-hosted runners: Might be easier to diagnose failures? They don’t recommend them for public repos for security reasons, so it’s not really a cost saving or capacity increasing pathway for us
- Unlike CircleCI, we can’t define our own Docker image (so run builds on a environment close to Silverstripe Ltd platform systems). You can just add named services through Docker
- Built-in artifact storage for 90 days, would be super handy for Behat screenshots
- We could publish a generic action for “Silverstripe module tests” on the marketplace, and make test integration easier for community devs? Here’s an example for Laravel tests
- Unfortunately, marketplace actions are copied into the repo on creation, so it’s not a way for us to centrally manage them