DEV Community

Discussion on: whats the best CI/CD service

View post
Collapse
 
ahferroin7 profile image
Austin S. Hemmelgarn •

It very much depends on what your exact needs are.

I'm personally rather fond of GitHub Actions though, because:

  • It's dead simple to use.
  • You can run jobs locally for testing (github.com/nektos/act)
  • You can run the actual tasks on your own infrastructure if you want to (anything supported by .NET Core 3.1 right now, but there is talk that they may be moving to Go or Node.js for the runner code).
  • The pricing is sensible and easy to understand (free for public GitHub repositories, pro-rated per minute of build time for private repos once you exceed a quota of free minutes).
  • It provides very good integration with PR's on GitHub (each individual job gets it's own entry in the PR checks, as opposed to stuff like Travis or CircleCI which have a single entry for all of the stuff they run).
  • They don't appear to have random networking issues like some services do (this has been a big issue with Travis for my current employer).
  • The default concurrency limits are higher than many other hosted CI services.
  • You can choose whether to have it bail early when the first job in a set fails or run everything to completion.

On the other hand, it does have it's issues:

  • Actions run against PR's from forks owned by people who aren't listed as contributors to the repo the PR is against can't access any secrets at all and don't have any write access to anything to do with the repo. This is good from a security perspective, but it seriously limits what you can do (for example, you can't actually reliably label a PR from GitHub Actions, because anybody who isn't a collaborator won't have the actions running with the required permissions to manipulate the PR labels).
  • As mentioned above, self-hosted runners are currently limited to platforms supported by .NET Core 3.1. This means no support for anything other than Windows, macOS, or Linux, and no CPU architectures other than x86, x86_64, ARM, and ARM64. This doesn't affect some people, but it's a showstopper for others. You can, however, work around this just like is possible with any other decent CI/CD system (that is, either use QEMU or just call out to another machine to run the tasks).
  • It is, of course, strictly tied to GitHub.