The much-awaited GitHub ‘Actions’ feature is all set to be released on November 13. This brings in a new facet of creating custom SDLC flows into GitHub and more importantly, we can build end-to-end CI/CD pipelines that are continuous integration (CI) and continuous deployment (CD) tasks, just as part of our code. In this article, we will try and explore GitHub Actions and implement the same to automate test case execution for our Rails application.

What’s Interesting About GitHub Actions?

  • No need for hosting. GitHub provides built-in Linux/Mac/Windows environments for executing the workflows.
  • Matrix builds to test multiple versions of the project (event in different runtimes) in parallel.
  • Live, shareable logging system enabled to make debugging life easier.
  • Keystore to save secrets and use them as environment variables.
  • Initial templates to get started with CI/CD automation.

How to Get Started?

GitHub leverages .yml and .yaml files to configure its workflows and we can have multiple workflows stored in ‘.github/workflows’ the folder at the root of the repository. So, we just need to sign up for the beta version and start creating .yml files based on this documentation provided by GitHub. Simple as that.

Effective Repository Management with Actions

We, at RootQuotient, use the combo of GitHub CI for test automation of feature branches. With the introduction of automated workflows on GitHub Actions, we wanted to give it a try and should say that the configuration is quite simple as it is more of a plug and play with all these open-source environments and workflows in place already.

So, I created a sample rails application (more sort of ‘hello world’) for this purpose and created a .yml file to configure the workflow:

name: Test CI CD
on: 
  push:
    branches:
      - master
  pull_request:
    branches:
      - master
jobs:
  build:
    name: Test Job
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@master
    - uses: actions/setup-ruby@v1
      with:
        ruby-version: 2.6.x
    - name: Install postgres
      run: |
        ./setup_postgres.sh -u ${{ secrets.DB_USERNAME }} -p ${{ secrets.DB_PASSWORD }}
    - name: Install bundler
      run: |
        gem install bundler -v 1.17.2
    - name: Install gems, migrate the database and check the code coverage
      run: |
        bundle install
        rake db:create db:migrate
        bundle exec rspec
        echo "success"
      env:
         RAILS_ENV: test
         DB_USERNAME: ${{ secrets.DB_USERNAME }}
         DB_PASSWORD: ${{ secrets.DB_PASSWORD }}
         DB_HOST: ${{ secrets.DB_HOST }}
         DB_PORT: ${{ secrets.DB_PORT }}

With this in place, we were able to mimic the test automation tasks just with GitHub and completely get off the dependency on circleCI. Though we are not at all comparing circleCI’s performance against this, this feature of GitHub would suite many small-scale applications around, just because of its simple setup. On the whole, this is exciting but should play the waiting game to see how GitHub Actions span out once they are live on November 13.

Is it just for CI/CD?

No. A Big NO. Once the Beta version was out, contributors started playing around with Actions and we are exploring a variety of use cases that can be addressed. Here are a few which seemed very interesting to me:

  • Cleanup branches after merge as done by waffle.io
  • Send discord notifications  using discord webhook based on any GitHub event with custom messages
  • Check code formatting while introducing new code. For eg., This particular action checks the formatting of docker files/Powershell code
  • Mabl’s new GitHub Action does cross-browser testing and I am sure that there is a lot more to come in the near future.

GitHub Actions vs GitLab Pipelines

Though the basic premise of these two remains the same, the difference mainly relies on its effective support for various use cases.

With parallelism being an important key to support abundant growth of complex builds, GitHub bets on its ‘matrix build’ to address parallel execution, even in different runtimes. On the other hand, though we can execute parallel jobs on GitLab by just changing the configuration file, the jobs still run in the same runtime environment.

GitLab focuses mainly on CI/CD builds and so it does a great job of solving that particular problem. But, when it comes to repository management, minor aspects like issue triaging can also consume a great deal of developer’s time. With that in mind, GitHub listens to a variety of repository events and can kick-off workflows on any such occurrence.
Everything said, there is a bigger arena to be discussed – SUPPORT. Apart from community support, we have no idea about dedicated support plans from GitHub Actions right now, whereas, we already have next business day support from the GitLab side for paid plans. So, let’s wait and see how GitHub reacts to this.