github

CI called pytest on an empty database while production applied migrations first; one workflow line aligned both contracts.

TL;DR: A test suite that passed locally kept failing in CI with misleading database errors. The root cause was that production ran Alembic migrations before boot, while CI pointed pytest straight at an empty Postgres. Adding alembic upgrade head before tests in the workflow made starting state deterministic, so failures now point at actual code.

The daily cron dump could not answer which release it matched. Pairing one dump with one release tag made restores a one-name lookup.

TL;DR: Daily cron dumps caused version confusion because the file wasn't tied to the app release. Now each annotated release tag gets its own logical mariadb-dump named to match, stored via documented rules and verified by test restores. This makes recovery predictable since the dump that matches production is instantly clear.

The secret-scanner hook crashed on a multi-file commit. One missing flag in the hook definition, and it ended with checksum-pinned CI.

TL;DR: The gitleaks system hook kept crashing on multifile commits because it mishandles the file list. Instead of waiting for a fix I switched to a local hook that runs a checksum verified binary on the staged diff. I apply the same strict pinning in CI with hashed downloads and minimal permissions accepting manual updates for stronger supply chain security.

The diff was docs-only, yet the deploy migration from Cloudflare Workers to Vercel still happened. The wiring lives in the Vercel dashboard and GitHub settings, not in the repo.

TL;DR: A docs-only commit revealed the Workers-to-Vercel migration left almost no trace in Git, since the wiring lives in Vercel and GitHub settings. Vercel elects the production branch only at import, so the GitHub default branch stag and production branch main are two independent switches. Env variables need per-target re-registration, and rollback is repointing a deployment, not git revert.

One folder or five scattered paths? The shape of your include set decides when subtree split is safe and when an rsync snapshot wins.

One WordPress install, two Git repos: a full Forgejo repo for recovery, a GitHub view repo carrying only source I wrote myself.

My per-commit dual-push ritual turned out more honest than a pull mirror that would quietly drop a 631 MB branch GitHub never had.

GitHub's 100 MB file block nearly ate a 631 MB backup bundle. The fix I picked: a self-hosted Forgejo secondary with proper mirror patterns.

A three-lane branch model for safe deploys: main as the source of truth, staging for Vercel previews, api for VPS deploys via GitHub Actions.