Gitlab

TL;DR In July I wrote about a test-deletion sentinel: CI hard-fails if a merge request deletes tests, unless the commit message carries a [test-refactor] tag and an issue number. I was pleased with it. It turns out a tag in a commit message is a bypass that an agent (or I, on a bad day) can write in one line, and it excused every test change in the MR, not just the one I meant. ...

TL;DR I built a private trip page for a week at a backcountry cabin in a large Ontario park, and nobody ever edited its HTML. Four JSON page specs go through a generator; every change is a typed operation that becomes a self-merging merge request. A GitLab CI schedule runs every 3 hours, pulls public Canadian weather, park and fire data, and commits a “conditions: refresh”. It made about 120 of those commits. The conditions script is stdlib-only, deterministic and offline-safe. If a source is down it keeps the last good copy, marks it stale, and never invents a number. The cabin has no cell service. Power and internet came from a Starlink Mini, a portable power station and a 120 W panel, and the whole workflow assumed a slow, metered link. Two real bugs: a bot that pushed as the wrong identity and got a 403, and a “fire” layer that turned out to be a static 2011 zone map. Why a page at all A week in the backcountry with a friend means a pile of shared decisions: gear, a meal plan with calorie math, a route with a water taxi and a portage, a charging plan for the drive, and some sense of whether we would be crossing a big lake in a 35 km/h wind. The usual answer is a group chat and a spreadsheet. ...

TL;DR Secrets leak through echo, debug tracing, logs, process args, and env-var inheritance — guard the flow, not just storage Fetch from Bitwarden once, assign to a shell variable, reference the variable — never inline the raw value Verify with first-3/last-3: ${VAR:0:3}...${VAR: -3} — confirm you have the right token without exposing it GitLab masked vars hide values in logs (8+ chars); protected vars only expose on protected branches — use both for production secrets Agent permission rules prefer command substitution inside the allowed command, not as an env var Rotate tokens immediately; verify before use; pin your bw CLI version The leak surface — where secrets escape I used to think storing secrets in Bitwarden (or Vault, HashiCorp, whatever) meant they were safe. I was wrong. ...

TL;DR I’ve wired LLMs into my GitLab CI pipeline to auto-review merge requests, post findings as comments, and (on command) generate patches and commit fixes. The key insight: deterministic gates run first. Before the LLM ever sees a diff, regex-enforced checks block deleted tests, committed secrets, and destructive commands. Regex is certain; LLM judgment is probabilistic. Gate first, judge second. The bot reviews silently unless it finds something, posts to the MR with confidence levels, and can be leveled up from read-only observer to trusted committer as it proves itself — hence the “autonomy ladder” (Rungs 0–4) that gates who decides what. Infrastructure repos cap at Rung 2 (never auto-merge). ...

TL;DR I moved every private homelab repo off GitHub onto a self-hosted GitLab CE 18.10 instance running on my k3s cluster. GitHub stays as a read-only mirror plus the break-glass k3s_bootstrap repo. Two weeks later I accidentally blkdiscard’d the GitLab volume and rebuilt the entire instance from an S3 backup. It worked, but the boring parts — runner re-registration, group tokens, container-registry pull secrets — were the real cost. Why bother GitHub was fine. GitHub Actions was fine. The thing that pushed me over was billing math plus blast radius: ...