Mike Fallows

Uploading Source Maps to Honeybadger with GitHub Actions

• 3 min

I’ve been a happy user of Honeybadger for well over a year now. For the small apps I’ve built it has often been enough to rely on users reporting bugs, as I usually have a direct line of contact with the user (AKA the client).

Error Tracking Shopify apps #

As the apps I’ve been building have become more complex and the number of users increased, it seemed prudent to add an error reporting service to my stack. I’d heard good things about Honeybadger, and I liked that they promoted good company ethics and had seen a lot of support in the development communities that I subscribe to. Their free tier seemed like it would cover my requirements comfortably, and allow me to scale as necessary. I was pleasantly surprised at how quickly I had error reporting set up in my apps, along with automatically generating GitHub issues for errors that were detected.

This was particularly the case for the backend of the apps that I typically develop in PHP with Laravel. They have a Laravel-specific integration which is a cinch to install.

Some of my most heavily used apps are integrated with Shopify and utilise Shopify’s React-based framework, Polaris. The JavaScript is minified for production so by default errors reported in JS can be obscured by the minification process. Often the nature of the error can reveal its origin, but that’s not always the case.

Using Source Maps #

Fortunately, it’s possible to provide Source Maps to Honeybadger which can then interpret the errors and identify their location in the source files. Much easier to debug!

Honeybadger can try to detect your Source Maps automatically, but by its nature, can be unreliable. A better solution is to upload the latest source maps to Honeybadger on each deployment.

This can be done in any number of ways, including a Webpack plugin or cURL.

Using GitHub Actions #

In the end, I decided to explore doing it via GitHub Actions. I have been keen to find an excuse to try them out since they launched but haven’t really needed to, or had the impetus to dig into it.

There is already a GitHub Package provided that handles the hard part of uploading the files to Honeybadger via their API. All I had to do was configure it correctly.

I clumsily added the Action via GitHub’s web interface, and after a couple of false starts (YAML is unforgiving), I had my first successful run and Source Maps uploaded. It took less than 20 mins in the end.

The final action looked like this:

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout repository
      uses: actions/checkout@v2

    - name: Install npm packages
      run: npm install --prefer-offline --no-audit

    - name: Build production assets
      run: npm run production

    - name: Upload source maps to Honeybadger
      uses: honeybadger-io/github-upload-sourcemap-action@master
      with:
        api_key: ${{ secrets.HONEYBADGER_API_KEY }}
        minified_url: ${{ secrets.PRODUCTION_URL }}/js/app.js
        minified_file: public/js/app.js
        source_map: public/js/app.js.map

I stored the API key for the project as a GitHub Secret to keep it secure, and I also stored the URL of the production site to make this action more portable. This works for me as I try to enforce building my apps in a consistent way.

Now each time the main branch is updated, the npm packages are installed, the production assets (including Source Maps) are generated and the latest Source Maps are uploaded to Honeybadger with a reference to the commit. So it’s much easier for me to track down the source of any JS errors that users generate in production (and of course, fix them 😉).

Tagged • ci • github actions