In software development, a feedback loop that takes time and effort could be a major bottleneck. Especially if we have to run things on remote servers and figuring out what’s going on requires lots of effort, debugging could make frustrations. Today, I’m going to introduce a couple of tools that help to debug GitHub Actions workflows from local machines.
Act With act command, you can run workflows on your local machine. Once you run act command it reads YAML files under .github/workflows and runs the jobs in Docker containers immediately. We can make sure if there’s any major problem in the YAML without making commit and pushing to GitHub. Although act does not provide 100% compatible environment with GitHub Actions, it helps a lot when you start writing workflow settings. For example, it is useful to find any errors and mistakes in the YAML file structure, dependencies between jobs, calling actions, and steps written in shell scripts.
When we have to process a large number of files, we should be aware of the resources the process consumes. Here’s the scenario I faced in my work recently: we have to create one archive file from lots of files that are stored on an S3 bucket. Created archive files must be placed on another S3 bucket. The number of files of an archive could be 700,000. The size of each file is up to 10MiB. The size of an archive file will be less than 140GiB.
Stripe provides an easy way to implement subscription services. This document explains how Stripe’s subscription works and the things you can. They also provide an example to implement fixed-price subscriptions, like Netflix. You can try the example repository on GitHub and see the whole lifecycle of a subscription. Actually, you don’t have to even set up any environment for the example app if you have Docker on your computer. The only dependency is Docker.
Sometimes I want to make multiple outputs from multiple processes into one single output. Let’s say we have to aggregate K8s pod logs from a deployment. We could do that by redirecting each output to a file and follow the file by tail -f like below.
tempfile=$(mktemp /tmp/rip-example.XXXXXXXXXX) trap "rm \"$tempfile\"" EXIT pods=$(kubectl get pods | grep Running | grep -oe "app-[a-z0-9\-]\+") for pod in $pods do kubectl logs -f "$pod" >> "$tempfile" & done tail -f "$tempfile" However, that method consumes disk spaces. Even worse, all the output data remains in the local disk if the process were killed with 9 (SIGKILL). There must be better ways. That’s where named pipe comes to play.
Sometimes I want to create a new gem or modify existing gems to extend/fix them. However, I do not want to install tons of additional development tools on my host machine for that. Recently, I created a shell script which creates an instant development environment on Docker for that.
#!/bin/sh -e exec docker run --rm -it \ --workdir=/work \ -v $(pwd):/work \ -v=$HOME/.gitconfig:/root/.gitconfig \ -v=$HOME/.ssh:/root/.ssh \ -v=$HOME/.gem/credentials:/root/.gem/credentials \ ruby:${VERSION:-2.6.5} \ /bin/bash "$@" This is a deadly-simple wrapper for docker command to run a ruby container mounting minimum-required files. Just put this file under a directory whatever it is in $PATH list (For example, /usr/local/bin/rubyshell) and run rubyshell in a Ruby project. Then I can do Ruby things such as bundle.
