Good oldies: MRSK and Rails ≤6

This article is outdated please read an updated version:

The decision seemed ideal, considering the application was already configured for deployment on a separate EC2 instance, and I had full confidence in a smooth Capistrano → MRSK transition.

However, as I added mrsk to the Gemfile and attempted to run bundle, a problem arose. It appeared that mrsk required activesupport >= 7 in its gemspec. I created a small PR, that downgraded activesupport dependency to >=6.1 which was enough for me and started to work on deployment configuration. PR has been closed and David pointed very right thing, MRSK is not needed to be included to the bundle to work. This is great! You can deploy whatever Rails application you have with it, the only thing that is needed is a Dockerfile.

In my particular case, I required an automated deployment process using GitHub Actions, as mentioned in my original article. The workflow I implemented utilized the setup-ruby@v1 action, which proved to be highly effective and handled caching seamlessly. To minimize any major changes and keep the process streamlined, I opted for a solution commonly employed in Ruby Gems testing, which involves creating a dedicated Gemfile for MRSK located in gemfiles/mrsk.gemfile. This approach allowed me to integrate MRSK seamlessly into my existing setup without disrupting the established workflow.

# frozen_string_literal: true

source 'https://rubygems.org'

gem 'mrsk', '~> 0.14'

After this you can run bundle.

BUNDLE_GEMFILE=gemfiles/mrsk.gemfile bundle install

Don’t forget to create a binstub to run MRSK locally and on a GitHub.

BUNDLE_GEMFILE=gemfiles/mrsk.gemfile bundle binstub mrsk --path ../bin

Congratulations! You have successfully installed the latest version of MRSK in your Rails 6 application (regardless of the specific version).

Now, let's proceed with updating your GitHub Actions workflow. There are two essential changes to be made: the setup of Ruby and the MRSK deployment process.

- uses: ruby/setup-ruby@v1
  env:
    BUNDLE_GEMFILE: ./gemfiles/mrsk.gemfile
  with:
    ruby-version: 3.1.2
    bundler-cache: true

- name: MRSK
  id  : mrsk
  env :
    MRSK_REGISTRY_PASSWORD: ${{ steps.login-ecr.outputs.docker_password_<YOUR_AWS_ACCOUNT_ID>_dkr_ecr_us_east_1_amazonaws_com }}
    DATABASE_URL: ${{ secrets.DATABASE_URL }}
    REDIS_URL: ${{ secrets.REDIS_URL }}
    RAILS_MASTER_KEY: ${{ secrets.RAILS_MASTER_KEY }}
    DOCKER_BUILDKIT: 1
    BUNDLE_GEMFILE: ./gemfiles/mrsk.gemfile
  run: |
    ./bin/mrsk deploy
  timeout-minutes: 15

As you can see, both jobs in the example above include the BUNDLE_GEMFILE environment variable, which points to our new MRSK-specific Gemfile. Apart from that, everything else remains unchanged.

This brief example highlights the fact that the Basecamp team has developed an exceptional tool that perfectly aligns with the needs and conventions of the Ruby community. Kudos!