-
Star
(109)
You must be signed in to star a gist -
Fork
(15)
You must be signed in to fork a gist
-
-
Save dhh/c5051aae633ff91bc4ce30528e4f0b60 to your computer and use it in GitHub Desktop.
| #!/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 |
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.
Hi @crohr, that is a valid point for Linux and Windows and therefore for most cases. For macOS though, there are not "many" alternatives and I would say that compared to Linux runners, there's nothing "cheap".
How is this used? I'm familiar with the git commit sign-off functionality but this is pushing directly to the GH API and I don't see the statuses reflected on the commits. Maybe there is an enterprise setting for enforced sign-off policies that cause it to be shown or something.
But I'm curious the full use case here rather than doing a more direct git --signoff and pushing a commit (or an amended unpushed commit).
For those landing on this gist from a Google Search, you might want to check the basecamp/gh-signoff repository where I believe this bash script has landed and will be maintained.
It's meant to be used as the last step of a local CI running on the developer's own workstation:
π https://x.com/dhh/status/1898307737991156120
π rails/rails#54693
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.