TL;DR

  • Fast
  • Promising
  • Integrated into GitHub
  • Less intuitive than Travis CI
  • Not yet totally ready (still in beta)

The code

My experience

Almost a month ago I had access to the public beta of GitHub Actions.

I implemented them on https-localhost, where I already had a continuous integration system with Travis CI.

I’ve tried both the old version (.workflow) and the new one (.yml).
I really enjoyed the intuitive and immediate drag and drop workflows. Furthermore, by editing the code by hand, any errors were reported by the GUI.
On the other hand, the YAML syntax is better known. My hope is that GitHub will port the WYSIWYG editor for the YAML, also because the old version will no longer be supported in a few days.b

Travis CI vs GitHub Actions

Performances

Although GitHub Actions is still in beta and has not had a great development, I find it very promising.

The main advantage is that GH offers a greater parallelization of tasks, and also the speed of each task is much better. A battery of tests that on Travis takes 10-15 minutes on GitHub Actions takes only 2-3 minutes.

Costs and plans

Both are free for public repositories, for private repos they adopt different strategies.

Travis CI has a fixed fee, starting at $63/year, with unlimited minutes and builds. The basic plan has only one concurrent job, the more you pay, the more concurrent jobs you have.

GitHub offers 2000 free minutes on all private repository with the free plan, and the minutes increase depending on the plan (pro, team, enterprise). It is possible to buy additional minutes at modest costs.

Travis CI is partially open-source, so you can run your own Travis CI server and use it for free for your continuous integration.

GitHub will soon offer a self-hosted solution too.

Setup

I found both setups reasonable, they are both fairly simple.

In this case, Travis is more intuitive. The current disadvantages of GH Actions are poor documentation and the lack of detailed and specific online guides. However, when it comes out of the beta and it starts to take hold, questions about Stackoverflow will flourish and everything will become easier.

How to build your own GitHub Actions workflow

Let’s see how to implement a simple GitHub Actions workflow using Node.js as an example.

  1. **name**

    name: CI
    

    This is the name displayed in the Actions tab of the repository.

  2. Trigger

    on: push
    

    The on keyword denotes when trigger the actions. You can also specify more than one event, like:

    on: [push, pull_request]
    

    Take a look at the entire list of events that trigger workflows.

  3. **jobs**: a list of jobs to be performed during the workflow.

    jobs:
      test:
        name: Test
        runs-on: ubuntu-latest
        steps:
          - uses: actions/checkout@v1
          - uses: actions/setup-node@v1
            with:
              node-version: 12
          - run: |
              npm install
              npm test
            env:
              CI: true
    

    In this example, there is only one job, identified with test and with name Test. It runs on the latest version of ubuntu. Each job is divided into **steps**, each step starts with a dash. The **uses** keyword invokes an existing action, in our case the library checkout and setup-node actions by the GitHub team.

    The **run** keyword directly execute a command, in our case npm install and then npm test. Use **env** to specify environment variables.

  4. **needs**

    You can put the jobs in sequence by specifying what other jobs are required before executing the current one. In the full code (below) the coverage job needs the tests.

  5. **matrix** allows you to run the same test in different environments.

    You can, for example, specify the os and the node version and the CI will run on all the combination. Check out the example in the full code. Note the tags runs-on and node-version of the test job.

    You can also exlude one ore more combination. For example, my CI runs on ubuntu, macOS and windows on node 8, 10, 11 and 12. But I have some problems with node version 8 on ubuntu-latest, so I excluded this configuration.

A complete example: npm test and Coveralls

    name: GitHub CI
   
    on: [push, pull_request]
   
    jobs:
      test:
        name: Test
        runs-on: $
   
        strategy:
          matrix:
            os: [ubuntu-latest, macOS-latest, windows-latest]
            node: [8, 10, 11, 12]
            exclude:
              - os: ubuntu-latest
                node: 8
   
        steps:
          - uses: actions/checkout@v1
          - name: Use Node.js $
            uses: actions/setup-node@v1
            with:
              node-version: $
          - name: npm install and test
            run: |
              npm install
              npm test
            env:
              CI: true
   
      coverage:
        name: Coverage (Coveralls)
        needs: test
        runs-on: ubuntu-latest
        steps:
          - uses: actions/checkout@v1
          - uses: actions/setup-node@v1
            with:
              node-version: 12
          - run: |
              npm install
              npm test
            env:
              CI: true
          - name: Coveralls
            if: success()
            uses: coverallsapp/github-action@master
            with:
              github-token: $