SETTING UP AUTOMATED TESTING ON YOUR REPO USING GITHUB ACTIONS

By: Saurav

2020-10-06 22:01:00 UTC

Hey my dudes!
If you work in a team or even individually and you have a production app, you need to test your code. Period.
If you think its okay not to think about testing, its just a matter of time before which you will feel you do need integration testing in your workflow.
I have worked with Circle CI in the past but recently Github launched Github Actions where they provide you a separate docker image which is used to run tests in.
The setup is pretty simple but figuring out the nitty gritty takes some time. I would walk you through how I setup one for a rails/redis/postgresql app and Gotchas I learned

1. Generate a .github/workflows directory and add a main.yml file

I did it in my app root folder

mkdir -p .github/workflows
touch main.yml

The -p option tells mkdir to create not only a subdirectory but also any of its parent directories that do not already exist.

2. Populate the main.yml file

There have been a lot of blog posts around this topic so I won't repeat the same. A good starting one is done by Chris and it really helped me get started fast. GitHub Actions with Ruby on Rails: Setting up Continuous Integration

Here is what it looks like for me

name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    env:
      POSTGRES_USER: your_username
      POSTGRES_PASSWORD: your_password
      POSTGRES_DB: your_DB
      REDIS_URL: redis://localhost:6379/0
      RAILS_ENV: test
    services:
      db:
        image: postgres:11
        ports: ['5432:5432']
        env:
          POSTGRES_USER: your_username
          POSTGRES_PASSWORD: your_password
          POSTGRES_DB: your_DB
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
      redis:
        image: redis
        ports: ['6379:6379']
        options: --entrypoint redis-server

    steps:
      - uses: actions/checkout@v1
      - name: Setup Ruby 2.7.1
        uses: actions/setup-ruby@v1
        with:
          ruby-version: 2.7.1
      - uses: borales/actions-yarn@v2.0.0
        with:
          cmd: install
      - name: Build and run tests
        env:
          DATABASE_URL: postgres://your_postgres_username:your_postgres_password@localhost:your_port/test
          POSTGRES_USER: your_username
          POSTGRES_PASSWORD: your_password
          POSTGRES_DB: your_DB
          REDIS_URL: redis://localhost:6379/0
          RAILS_ENV: test
          COOL_ACCESS_TOKEN: ${{secrets.COOL_ACCESS_TOKEN}}
        run: |
          sudo apt-get -yqq install libpq-dev
          gem install bundler
          bundle install --jobs 4 --retry 3
          bundle exec rails db:setup
          bundle exec rspec spec

3. Gotchas

I face multiple issues and resolved them one by one to get to this.

1. Github doesn't hoist the Environment variables. So you will get an error when GA will try to install postgresql and start it.
> That's why its important to replicate the ENV variables especially related to postgresql before the services key and in the build and run test step

test:
    runs-on: ubuntu-latest
    env:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
      POSTGRES_DB: postgres
      REDIS_URL: redis://localhost:6379/0
      RAILS_ENV: test

2. For rspec tests, you need to change the last line to bundle exec rspec spec
3. For postgresql you need to provide password in the DATABSE_URL env variable (postgres://your_postgres_username:your_postgres_password@localhost:your_port/test)
4. Make sure the version of Ruby is same as your gemfile
5. Its best to have same version of potgresql and redis as your production app.

3. Set up secrets using Setting > Secrets

and refer to them using ${{secrets.COOL_ACCESS_TOKEN}} if your tests rely on a secret. You can also setup a connection to your heroku by using the heroku secret if you need to (for example your sandbox database). I didn't

You can set this up in a pull request and then merge and deploy to the master branch.
From then on, any new push/pull request will invoke the test which you can check as shown below. If anything goes wrong, the clustering of steps as shown below allows you to pin point the exact cause of the issue and fix it.

Screen shot 2020 10 06 at 3.26.34 pm

Screen shot 2020 10 06 at 3.35.45 pm

Owned & Maintained by Saurav Prakash

If you like what you see, you can help me cover server costs or buy me a cup of coffee though donation :)