signoff

#!/usr/bin/env bash

# Abort sign off on any error
set -e

# Start the benchmark timer
SECONDS=0

# Repository introspection
OWNER=$(gh repo view --json owner --jq .owner.login)
REPO=$(gh repo view --json name --jq .name)
SHA=$(git rev-parse HEAD)
USER=$(git config user.name)

# Progress reporting
GREEN=32; RED=31; BLUE=34
announce() { echo -e "\033[0;$2m$1\033[0m"; }
run() {
  local SPLIT=$SECONDS
  announce "\nRun $1" $BLUE
  eval "$1"
  local INTERVAL=$((SECONDS-SPLIT))
  announce "Completed $1 in $INTERVAL seconds" $GREEN
}

# Sign off requires a clean repository
if [[ -n $(git status --porcelain) ]]; then
  announce "Can't sign off on a dirty repository!" $RED
  git status
  exit 1
else
  announce "Attempting to sign off on $SHA in $OWNER/$REPO as $USER" $GREEN
fi

# Required steps for sign off
run "./bin/rubocop"
run "./bin/bundle-audit check --update"
run "./bin/brakeman -q --no-summary"
run "./bin/rails test"
run "./bin/rails test:system"

# Report successful sign off to GitHub
gh api \
  --method POST --silent \
  -H "Accept: application/vnd.github+json" -H "X-GitHub-Api-Version: 2022-11-28" \
  /repos/$OWNER/$REPO/statuses/$SHA \
  -f "context=signoff" -f "state=success" -f "description=Signed off by $USER ($SECONDS seconds)"

announce "Signed off on $SHA in $SECONDS seconds" $GREEN

Neat, thanks for sharing. Might also consider moving some things into a justfile - we are using that tool heavily across our projects now. Easy to add tasks for linting, formatting, tests, sanity checks, CI, deployment, foreman, builds, setup, whatever. Language agnostic, self documenting, handy for new hires, autocompletes in the shell, etc.

As a variation/alternative/improvement (!) to this, I considered using the devs' machines as runners. We need to assume that the workflows would install the required dependencies etc.

Very much valid what @skyscooby said about running on containers - in my scenario, bare-metal macOS instances are used (not virtualised) and availability can be scarce.

Here's a way to optionally use the devs' machine that when connected to GitHub Actions should have a label with the name of the branch.
If the dev machine is not connected as a dev-hosted runner, the workflow will try to run on self-hosted runners (shared instances), potentially sitting on the queue.

It could be an interesting option for some teams under certain conditions.

• 🙂 GitHub-hosted runners
• 💸 self-hosted runners
• 👀 dev-hosted runners

@albertodebortoli or... one of the many drop-in replacements for official runners, but far cheaper? At least for jobs that can't be easily launched / take too long on a dev machine.