5 posts tagged with "automation"

A Trick is the most boring primitive we have. It runs your container once, watches it finish, records the exit codes, and tears itself down. No routing, no Genie, no second act. So when someone proposed building "self-healing CI" on top of it, the obvious reaction was: with what? There's nobody home in a Trick.

That turned out to be the point. The Trick stays dumb; the intelligence lives elsewhere — a separate coding Genie that wakes up after the job is done, reads what went wrong, and tries to fix it. Compose a one-shot job with that out-of-band agent and you get a loop that runs your tests and, when they're red, takes a swing at making them green. We call the patterns CI-Job and Muti-Job, and the cleverness is never inside the Trick.

You already have a Trick — a job-mode Template that runs your tests, takes a backup, or migrates a database, then exits and records a result. So far you've been launching it by hand. The next move is to stop: have Fibe fire it at 3 a.m. every night, or fire it the instant someone pushes a commit. Both are two extra keys in the template's metadata block. No external cron daemon, no GitHub Actions YAML, no second CI runner that drifts away from your dev environment.

This guide is the hands-on version. We'll wire up a nightly Postgres backup on a cron schedule and a test-runner that fires on every pull request, and we'll be precise about the parts that trip people up: which branch a triggered run actually checks out, why a schedule that "should" fire at midnight runs at the wrong hour, and what Fibe does not tell GitHub when a run finishes.

The browser is great for poking at a Playground. But the moment you want a launch to happen on push, or you want to spin up the same environment fifty times in a load test, or you want a Slack bot that reports which of your Playgrounds are unhealthy — you want the terminal. That's what the fibe CLI is for, and underneath it, a Go library you can embed directly in your own programs.

The nice part: it's one binary. The same executable you brew install is the CLI, the Go dependency, and an MCP server for AI agents. Same auth, same resource model, same retry logic. This guide walks you from brew install to a fully scripted launch — install, authenticate with profiles, fire a launch, wait for it to come up, and read its URL — then shows when to drop down into the Go library instead.

Most platforms ship a development environment and a CI system as two separate products. They drift. What worked in your dev container fails in CI for reasons nobody can reproduce, and you lose an afternoon discovering the CI runner is on a different base image, network, everything.

We didn't want two runtimes. A Trick is a Playground with one flag flipped — job mode — running the exact same environment engine, on the same Marquee, from the same Template. It has no UI to attach to and a defined notion of done: it runs, it exits, it records a result. If your tests pass in a Playground, they pass in a Trick — there's no second runtime to drift away from.

Most of your stacks are supposed to stay up. A web app, a worker, a dev server — you launch it, it serves, you keep it running. But a lot of the work you actually run against a project is the opposite shape: it should start, do one thing, and stop. Tests. A migration. A nightly backup. CI on a push. For that work, a long-running Playground is the wrong tool — it has no idea when it is finished, so it just sits there, holding resources, waiting for a URL that nobody is going to hit.

A Trick is Fibe's answer for the second shape. It is the same environment engine as a Playground — same Compose file, same Marquee, same logs and terminal — but Fibe treats it as one-shot: it runs the watched service to completion, records whether that service exited cleanly, tears the containers down, and keeps the result. This guide walks you through building one from scratch, with a real test-runner example, and explains the three things people get wrong the first time.