Happy Launch Day! If you weren’t aware, Release came out of beta today. Here are some links to news articles related to our launch.
If you’ve ever encountered the above message when logging into Docker and thought to yourself “Well it’s unencrypted but it works… I’ll deal with it another day” then we’ve got something in common. That day finally came when I was working on another blog post but realized that without a secure way to do a
docker login I was never going to achieve a good working example to write about. I came across docker-credential-helpers which looked like exactly what I needed. One of the recommended ways to store the…
Check now 😎— Nat Friedman (@natfriedman) August 17, 2019
What a wonderful day that was! I’ve been playing around with Actions ever since and one of my new projects, a Ruby Gem, didn’t have any form of CI as of this morning. I set out to create an Action that would run the tests for the gem and produce coverage results via SimpleCov. While it’s nothing too extravagant, there was a small nuance that I had to resolve and I decided I wanted to share that info.
Let’s start off with some changes to the
if ENV.fetch('COVERAGE', false) SimpleCov.start do minimum_coverage 90 maximum_coverage_drop 2 end end
This ensures that the coverage is above 90% and any changes in the future must not drop the coverage by more than 2%. The Gem, in its infancy, does not pass this requirement. Due to that failure, I had to figure out why the Action was not uploading the coverage results. Remember to put the
SimpleCov code at the very top of
spec_helper.rb, before you do
Recently, I started working on a new side project in Elixir and I think I’ve finally found something I’m going to stick with! In the past I would either build something like a simple TODO app and not get far enough into the language or I would pick a gigantic idea and get nowhere due to how daunting it was. However, one of my co-workers recently implemented a feature through the Github Webhooks API where we are required to add a label to our Pull Requests and a Slack channel is notified that the…
I was recently attending DockerCon and Michael Ellison, CEO of Codepath, was giving a talk about the future of Computer Science education. He was telling a story about how he was recently in a room with a large number of CTOs and asked how many of them started programming before the age of 14. He mentioned that around 90% of them raised their hands. I let out an audible chuckle, turned to the person next to me and said “Well time to change careers, looks like I’ll never be a CTO.” While being a…
Recently, I decided that one of my goals for 2019 was to familiarize myself more with Docker. I’ve been exposed to using Docker for the past couple of years, but I don’t use it on a day to day basis. Every once in a while, I would need to update a Dockerfile or a script and I would realize I needed to brush up on mostly everything because it had been so long since the last time I looked at anything Docker related. I decided I would just dive in and read a book to familiarize myself with any…
An update to my post on adding a testing environment to a gem. After doing some recent updates to our Docker images at work, I realized that we are always using Ruby Alpine images, and not the base Ruby image. I can’t remember why I built the gem’s Dockerfile using the base Ruby image, perhaps I had just overlooked the fact that we used Ruby Alpine, but I wanted to standardize the Dockerfiles I had written at work and here for the blog so I decided to look into what it would take to do so.
Continuing to work on our gem with active_record rake tasks, we still need to set up a testing environment that can be run locally and in a repeatable fashion for continuous integration; we’ll accomplish the latter using a simple Dockerfile. But first let’s make it easier for someone to start using the gem by enhancing the scripts in
We’ll start off by changing
bin/setup to create the user and the database.
#!/usr/bin/env bash set -euo pipefail IFS=$'\n\t' set -vx bundle install psql -tAc "SELECT 1 FROM pg_roles WHERE rolname='gem_with_database'" | grep -q 1 || \ psql -c "create role gem_with_database with superuser login password 'password'" psql -tAc "SELECT 1 FROM pg_database WHERE datname='gem_with_database_development'" | grep -q 1 || \ rake db:create db:migrate db:seed
The first command queries the
pg_roles table looking to see if there is a role named
gem_with_database and returns 1 if so. The result is piped into
grep looking for the 1, if it is found we stop, otherwise we issue another command to create the
gem_with_database role. If you’re curious as to how this works,
grep returns a non-zero exit code if it doesn’t find something and a bash
This is a follow up to my last post about Adding ActiveRecord Rake Tasks to a Gem that I promised to write. In that post I had to figure out how to make the command
rails g migration accessible inside of the gem, which ended up taking me all afternoon, but surprised me in how little code was actually needed to achieve the result. I wanted to write about the process I went through to figure out what was needed; I believe it is good exercise in understanding how to follow code to and understanding what it takes to…
In my previous post I walked through using a gem to connect to another Rails application’s database, but another use case for connecting a gem to a database is for the development of the gem itself. Instead of having to create a Rails application and install the gem to connect to the database to test your models, we can create local database for only the gem by adding ActiveRecord’s Rake tasks.
There will be a lot to go through so I’m going to break this down into two parts: the first being creating the gem and enabling the usage of familiar tasks such as
db:migrate, the second being setting…