-
-
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 |
Is your CI slow because you reinstall earth every commit ? Having buildpack image and cache should help.
In ldap2pg, I end up running docker compose right in CircleCI machine executor. Docker executor don't have enough privileges to run Samba service. docker compose run test is a reproductible local or remote test environment. This is not a pipeline however. Some CI have local execution tooling. That may help.
Hopefully this script is being invoked inside a shared container runtime with managed dependencies so every developer is running the exact same tool versions.
The other option is to use Nix. Then, nix build is reproducible across all machines of same architecture; you can even build docker images in Nix.
@dhh will find Nix to be the next red-pill, sooner or later. :-)
I personally run GitHub runners locally (setup through Nix) which happens to me on my laptop, but that doesn't obviously scale to N developer machines/
is to use Nix
You must have missed his many other posts on complexity being a temporary bridge to simplicity.. Nix has only gotten more complex since it's inception.
The moment you need to either build your own packages or troubleshoot someone elses, you are faced with mountain of needless complexity. It certainly isn't a tool that should have required a unique turing complete language to achieve.
If everything works out as a user and you never have a Nix language issue, or a need to touch it, then it can work out ok.. but https://containers.dev is a more general solution for developers.
Does this hook into deployments, e.g. once a commit has a successful signoff status it can be automatically rolled into staging?
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.
Hopefully this script is being invoked inside a shared container runtime with managed dependencies so every developer is running the exact same tool versions.
It might also be reasonable from a security perspective to have your deploy branch running these tools on a machine that is isolated to prove reproducible deployment on a machine less likely to become compromised than a dev desktop. In a jam a developer might also just decide to
#comment out any one of thoserunstatements and you'd really have no central logs/output to review/audit. Maybe you could use the gh api to upload the output of the above jobs into the signoff somehow?You can also do something similar with a git pre-commit hook.. https://github.com/pre-commit/pre-commit