DEV Community: David Wessman

Blinka - Connecting Heroku CI to Github

David Wessman — Wed, 10 Feb 2021 19:31:27 +0000

Heroku CI (continuous integration) runs tests in an environment very similar to an Heroku application, the code is packaged into a slug and runs on a dyno.

With Heroku's Github Integration it can automatically run CI-builds for every commit, then report back to Github with a pass or fail status and a link.
The test results can be parsed if they are reported in the TAP-format, but it still stays on Heroku and is not visible on Github.

What if we could get the number or failing tests, error messages, backtraces and even screenshots directly to Github?

This is why I built Blinka🚦!

Setup

Configure your application for Heroku CI.
Install blinka-reporter by adding it to Gemfile using

bundle add blinka-reporter

Get BLINKA_TEAM_ID and BLINKA_TEAM_SECRET from Blinka🚦 - the only way to do this today is reaching out to me on Twitter @davidwessman.
Add the values from step 3 to Heroku CI environment variables.
Add the Github App blinka-bot to the repository.
Add Blinka-configuration to the testing part of the Heroku configuration in app.json. Mine looks like:

  "environments": {
    "test": {
      "addons": [
        "heroku-postgresql:in-dyno",
        "heroku-redis:in-dyno"
      ],
      "buildpacks": [
        {
          "url": "https://github.com/heroku/heroku-buildpack-google-chrome"
        },
        {
          "url": "https://github.com/heroku/heroku-buildpack-ruby"
        }
      ],
      "env": {
        "BLINKA_REPORT": "true",
        "BLINKA_REPOSITORY": "davidwessman/synka",
        "BLINKA_TAP": "true",
        "WD_CHROME_PATH": "/app/.apt/usr/bin/google-chrome-stable"
      },
      "formation": {
        "test": {
          "quantity": 1,
          "size": "standard-2x"
        }
      },
      "scripts": {
        "test-setup": "bin/yarn && bin/rails webpacker:compile",
        "test": "bin/rails test:system test"
      }
    }
  }

Before blinka-reporter version 0.3.3 you had to do the reporting separately, this is now handled by setting BLINKA_REPORT=true.

Bonus

The gem blinka-reporter also supports outputting test results in TAP-format, without depending on anything but minitest.
Enable by setting the envionment variable BLINKA_TAP=true. This allows Heroku to parse the results and report them in their interface.

Results

With failing tests

The tests run on Heroku CI and with the TAP-format output we get some feedback in the Heroku interface.

The test results are reported to Blinka🚦 which results in a Github Status:

A comment with the results of the CI-run is posted:

It can even handle screenshots generated from a failing test, upload them to the service and include them in the comment:

Please reach out to me on Twitter if you want to learn more!

Rails Dual-boot + Dependabot = 💔?

David Wessman — Sun, 13 Dec 2020 18:26:48 +0000

There are two concepts which greatly affected how I work with Rails development during the last couple of years, specifically with dependency management and preparing for upgrading to the next Rails version.

The first one is Dependabot which opens pull-requests to update one dependency at a time. This way of working felt natural at once and allowed me to be on top of dependency updates instead of being scared of it 👻.

The second one is dual-booting my Rails applications using separate lock-files, I was introduced to this concept by fastruby.io and their blog post Getting Ready for Rails 6.0: How to Dual Boot.

Unfortunately the two do not work well together out of the box 💔.

When using dual-booting of Rails, we specify the dependencies in the Gemfile like this:

def next?
  File.basename(__FILE__) == "Gemfile.next"
end

if next?
  # Specific override for next
  gem 'rails', '~> 6.0'
  gem 'rubyzip', '~> 3' # Allow freer version
else
  gem 'rails', '~> 5.2'
  gem 'rubyzip', '> 2', '< 3' # Lock this to specific version compatible with Rails 5.2
end

gem 'webpacker', '~> 5.1.0' # Same version for Rails 5.2 and 6.0.

This allows us to prepare working with higher versions of specific gems if needed.
The next?-block is used if the Gemfile we use is called Gemfile.next.
In order to use this we create a symbolic link, so our gemfiles in the project folder look like this:

Dec 13 13:07 Gemfile
Dec 13 12:57 Gemfile.lock
Dec 13 12:57 Gemfile.next -> Gemfile
Dec 13 13:08 Gemfile.next.lock

This means Gemfile.next will refer to our usual Gemfile but next? will be true.

Problem

When Dependabot updates our dependencies it is configured to find Gemfile and Gemfile.lock and see if they need updating.

Lets say that webpacker releases a new version and needs to be updated to version 5.2, if we have a version requirement in the Gemfile that does not allow to update to the latest version, then Dependabot will update both Gemfile and Gemfile.lock.

Since Dependabot does not update Gemfile.next.lock it will get out of sync with our Gemfile:

# Gemfile - updated by Dependabot
gem 'webpacker', '~> 5.2.0'

# Gemfile.lock - updated by Dependabot
webpacker (5.2.0)

# Gemfile.next.lock - not updated
webpacker (5.1.0)

This works in development, but in deployment using BUNDLE_DEPLOYMENT=1 we get an error:

% BUNDLE_DEPLOYMENT=1 BUNDLE_GEMFILE=Gemfile.next bundle
You are trying to install in deployment mode after changing
your Gemfile. Run `bundle install` elsewhere and add the
updated Gemfile.next.lock to version control.

If this is a development machine, remove the <project-path>/Gemfile.next freeze
by running `bundle install --no-deployment`.

The dependencies in your gemfile changed

You have added to the Gemfile:
* webpacker (~> 5.2)

You have deleted from the Gemfile:
* webpacker (~> 5.1)

There have been discussions about using multiple Gemfiles on Dependabot, but the proposed solution did not work well with symbolic links in the Github API:

Solution

Instead of trying to configure Dependabot differently I wrote a Github Action to update the Gemfile.next.lock anytime Gemfile.lock is updated.

The steps in the Action are:

Trigger on every pull-request.
Check if Gemfile.lock was updated.
Generate an access token using a Github App, based on this article.
Checkout the code using the generated access token.
Install ruby.
Update dependencies using Bundler.
Commit if there are any changes using EndBug/add-and-commit.

Here is a gist and it looks like this:

name: Update next

on:
  pull_request:
    paths:
      - "Gemfile.lock"

jobs:
  update:
    runs-on: ubuntu-20.04

    env:
      BUNDLE_GEMFILE: Gemfile.next

    steps:
      - name: Generate token
        id: generate_token
        uses: tibdex/github-app-token@v1
        with:
          app_id: ${{ secrets.APP_ID }}
          private_key: ${{ secrets.PRIVATE_KEY }}

      - uses: actions/checkout@v2
        with:
          token: ${{ steps.generate_token.outputs.token }}

      - name: Set up Ruby
        uses: ruby/setup-ruby@v1

      - name: Gems Cache
        id: gem-cache
        uses: actions/cache@v2
        with:
          path: vendor/bundle
          key: ${{ runner.os }}-gem-${{ hashFiles('Gemfile.next.lock') }}
          restore-keys: |
            ${{ runner.os }}-gem-

      - name: Update Gemfile.next
        run: |
          bundle update --minor --conservative

      - uses: EndBug/add-and-commit@v6
        with:
          add: Gemfile.next.lock
          message: 'Updated Gemfile.next.lock'

The above action should be saved as .github/workflows/<workflow-name>.yml to get automatic updates.

Future work

The bundle strategy can probably be tweaked to something other than bundle update --minor --conservative.

Please get in touch with me on twitter @davidwessman if you have any questions or suggestions!

Updates

2020-12-13

When using a GITHUB_TOKEN, the added commit cannot trigger Github Actions again. This can be solved by using a Personal access token (PAT) as I learned from Github user airtower-luna (Thank you!) in this discussion.

2021-01-14

The initial setup used the default GITHUB_TOKEN from the Github Action, and it cannot be used to trigger another Github Action job.
Added a setup using an access token from a Github App, allowing new jobs to be triggered.

Error when converting PDF to image on Github Actions

David Wessman — Thu, 15 Oct 2020 13:19:44 +0000

Error:
Documents::UploadJobTest#test_#perform_creates_an_activity_for_document:
MiniMagick::Error: `convert /tmp/shrine20201009-22018-5itpj9.pdf[0] -auto-orient /tmp/image_processing20201009-22018-1uk39lv.png` failed with error:
convert-im6.q16: not authorized `/tmp/shrine20201009-22018-5itpj9.pdf' @ error/constitute.c/ReadImage/412.
convert-im6.q16: no images defined `/tmp/image_processing20201009-22018-1uk39lv.png' @ error/convert.c/ConvertImageCommand/3258.

    app/uploaders/document_uploader.rb:13:in `block in <class:DocumentUploader>'
    test/jobs/documents/documents_upload_job_test.rb:8:in `block in <class:UploadJobTest>'

In my Ruby on Rails application, this error is raised when using MiniMagick to convert a PDF into an image.
MiniMagick uses ImageMagick which uses Ghostscript for anything related to postscript files - for example PDFs.

Due to a security vulnerability in Ghostscript < 9.24, ImageMagick changed the default policy to not allow conversions using Ghostscript.
Even if Ghostscript has fixed the vulnerability, the ImageMagick policy has not been changed.

In my application I use MiniMagick via a gem called Shrine where a PDF is processed to get a thumbnail. To read more about this, please visit the Shrine documentation.

On Github Actions the default linux image is Ubuntu 18.04 (20.04 in preview).
Ubuntu 18.04 should have an updated version of Ghostscript, but still has a policy for ImageMagick that disallows conversion from PDF to an image.

Solution

My solution was inspired by this StackOverflow answer.
It can be added to a Github Action like this:

# ---
jobs:
  job01:
    runs-on: ubuntu-latest # ubuntu-18.04
    steps:
      - name: Change ImageMagick policy to allow pdf->png conversion.
        run: |
          sudo sed -i 's/^.*policy.*coder.*none.*PDF.*//' /etc/ImageMagick-6/policy.xml
      - <more steps>

Mac OS

If you experience this error on Mac OS it can be helpful to reinstall ImageMagick and Ghostscript:

brew uninstall ghostscript imagemagick
brew install ghostscript imagemagick

gs --version # make sure it is > 9.24 (9.53.3 on my machine currently.)
magick --version # make sure the row `Delegates` includes `gslib`

Rails: Minitest results output in TAP-format for Heroku CI

David Wessman — Sat, 18 Jul 2020 20:31:38 +0000

When using Heroku CI for automatic testing, the default output is just pass or fail without any parsing of how many tests passed or what errors where found.

This can be improved if you output the results in the Test Anything Protocol-format (TAP-format) according to Heroku.

This format is not built into the test frameworks used in Ruby on Rails. Therefore I had to write my own test reporter.

I chose to implement this for Minitest and decided to use the gem
minitest-reporters.

Expected outcome

I have a small project where the test suit looks like this:

To adhere to the TAP-format I need it to also output:

TAP version 13
1..7
ok 1 - AccountsControllerTest - test_renders_users_account
ok 2 - AccountsControllerTest - test_require_login
ok 3 - CallbacksMessagesControllerTest - test_handle_status_callback
ok 4 - MessagesControllerTest - test_should_create_message
ok 5 - ContactsControllerTest - test_should_create_contact
ok 6 - ContactsControllerTest - test_should_update_contact
ok 7 - ContactsControllerTest - test_show_contact

Solution

I created a custom reporter called TapReporter by inspecting a standard reporter from the minitest-reporters gem called ProgressReporter (see source):

The solution on Heroku

A failing test

Successful tests

Keywords

Ruby on Rails.
Heroku - Platform as a Service, useful for hosting web applications.
Continuous integration (CI) - in this post it mostly refers to automated testing.
Test anything protocol(TAP) - a protocol for test results.
Minitest - a test framework for ruby.