Sayan's Blog

GitHub Actions: A brief good/bad analysis

Published on May 1, 2021

GitHub Actions was GitHub’s take at CI/CD providers and also a very rational response to competitor GitLab’s CI/CD. The fact that your CI/CD lives right next to your SCM is absolutely amazing and is one of the selling points for GitHub Actions for many.

The good part(s)

There are several things that make GitHub Actions very appealing; a few of these are:

  • It’s right next to your code; like literally an ‘Actions’ tab lying close to your ‘Code’ tab
  • It is free for open-source (with some limits); this is a big selling point for me as I write open-source code almost all the time
  • It is open source, itself. That’s right, you can find sources for the runner, the virtual environments, etc right here; being an open-source evangelist, this is absolutely amazing!
  • 2500 free CI minutes per month for private repos
  • Third party actions; just create a repository on GitHub, add an actions.yml and related files and let the world use your GitHub Action

The bad bit(s)

At Skytable, we have more complexity in our workflow than the average user (an average user is, say someone who runs tests against multiple versions of a toolchain). We release artifacts on every commit, need to test on 32-bit and 64-bit environments, have dependencies, need to build Docker images and push releases. But the story doesn’t end there — our upcoming test suite will also include stress tests along with several other suites which would make our workflow even more complex. But, … you just define workflows and run them….isn’t it so? Oh well, here come the problems.

#1: Lack of runner customizability

GHA apparently has a plan for customizing runners but that plan itself is about two years old and I’ve got no clue when we can see that coming into action. This is a big problem for users who have workflows that require a lot of resources and are otherwise very slow.

And, you’d want to talk about self-hosted runners then. Well, that’s the next point.

#2: The self-hosted controversy

Even though self-hosted runners are free to install, of course on your own infrastructure — they’re not so safe unless you trust what will be run on it…..what? Ummm yes. Self-hosted runners are run directly on the host machine without any sort of isolation and anyone who runs a ‘bad’ PR can essentially do bad things to your machine.

Some folks built a dockerized version of the runner, but it isn’t officially supported (so you have no one to shout at for security issues). Albeit running things in a Docker container isn’t usually problematic without escalated privileges, but still, people are always picky about what they run on their own machines. Also, there’s no way to prevent PR builds (as of April 30, 2021) from running on self-hosted runners. Also, anyone can push an update to your workflow file that can be used to run the PR itself on a self-hosted runner.

So, if you’re thinking to run pull request builds on GHA infra and pushes on your own infra, that isn’t happening — even though this is likely the ideal solution to prevent bad actors from exploiting self-hosted runners.

Conclusion

GHA is easy, powerful and a free to use as a CI/CD service. I will almost always recommend using GitHub Actions for your CI/CD needs and it almost has everything you need to get your continuous integration/delivery in place. But if you have slightly complex needs, for now, you might want to take a look at alternative providers like Circle CI, Travis CI, AppVeyor and several others. When GitHub resolves the #1 and #2 points, I don’t see why it wouldn’t become the best CI/CD service around.