I have been using Travis CI for my continuous workflow needs for a very long time now. It does what it does and it does it well. However, Travis is an additional service you have to configure and login to, it is a bit disjointed from the code itself.

When GitHub announced Actions, it was a game-changer. Essentially, it was Travis CI embedded into GitHub itself. Over time, the community have run with GitHub Actions and now there are numerous “recipes” to do tasks inside of your actions.

When the feature was first announced and released, it had some teething issues. I actually gave up on GitHub Actions after running into issues I just didn’t bother working around and stuck with the tried and tested Travis CI.

Fast forward to now and I have begun switching over my own projects to use GitHub Actions as well as numerous Npm packages and open-source projects I contribute too are also equally making the switch.

To me, one of the biggest drawcards of GitHub Actions is they are coupled to the repository itself. I try and reduce the number of external dependencies in my projects as much as possible (within reason).

In the past, I have run into issues configuring Travis CI. I once struggled getting Travis CI setup to rsync some files via SSH to a remote server, spending hours upon hours trying to use the Travis CLI to generate an encrypted file in the format it expects .enc I eventually got there, but it as painful.

Ironically, I recently was tasked with creating a build in GitHub Actions that deployed via SSH and it was easy, using a script from the marketplace, I had it all working in five minutes. You can store the private key itself inside of a secret (which is not visible to anyone).

I was never doing anything overly complicated in Travis CI, so I doubt I will notice any difference switching over. The speed of GitHub Actions does seem to be faster (in both spin up and build time), so that is a huge plus.