You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Bots that test a release candidate before it ships #85
A candidate gets cut: a build, a tag, something ready to go out. Nobody actually runs it against the real thing it has to work with until it's already tagged, flashed onto a device, or installed somewhere that matters, and doing that run keeps falling to whoever happens to have the bench, the lab, or the test rig free that week.
Building the candidate and exercising it against its real environment, the standard checks a person would run by hand, is mechanical enough to run on every candidate without waiting for someone's afternoon. What it should bring back to a person is whether what it saw holds up as ready to ship, because the actual go-ahead is still the maintainer's call to make and stand behind.
We'd take one per artifact kind: firmware run against real hardware, a mobile build run against a device farm, an installer run against a clean machine image.
New here?gitbot runs Claude Code, Codex or OpenCode as reusable bots on your own machine, with your logins and your files. You define a bot once, a name and a job in plain English, and run it in as many folders as you like.
npm install -g @gitbot-hq/gitbot
gitbot start
Built one for this? Finished bots go into this library, each listed under the GitHub account that built it. In GitBot, the share menu on a bot has a Publish to Marketplace option that opens the pull request to add it. Your instructions go in as written.
These stay open after the first bot lands. And yours doesn't need to be general: people install the bot that's built for the stack they're already on.
Activity