Sessionboxer

Working with code

Automations: a trigger, an action, limits and a run history

Sessionboxer acts without a prompt from you: on a cron timetable, or when a followed pull request opens, changes or fails a check, it prompts a session, starts one, posts a review or an Auto QA video. Limits per automation, runs listed with their outcome.

Feature page: Automations — screenshots, things you can do with it and how other products compare.

Automations in the sidebar (next to Global settings) is where Sessionboxer does things for you without a prompt from you: on a timetable, or when a pull request you follow changes. An automation is a trigger, an action and limits; the Control Plane runs them while it is up, and every run is in its history.

Triggers. On a schedule: a cron expression (0 9 * * 1-5, @hourly, …; the field suggests common ones and shows the expression in plain words plus the next three run times), a time zone (IANA name, your own by default) and what to do with runs missed while the Control Plane was off — Skip them (default, recorded as skipped) or Run once when the Control Plane is back (one catch-up run, however many were missed). When a followed pull request changes: pick which follows — the ones from the Pull requests page, or Follow a repository right there (login to read with, owner/repo or URL, suggestions from the repositories you named before) and it is ticked; My PRs and Reviews asked of me are followed from the Pull requests page — and which events — opened, new commits, ready for review, converted to draft, review requested, review submitted, comment, check failed, merged, closed, reopened — with filters for drafts (skipped until ready for review by default), PRs from forks (reviewed but never run by default), the author (not your own PRs by default; optionally only a list of logins), who is asked to review (a list of logins and, on GitHub, teams as org/team — both lists suggest the people seen on your followed PRs, and review requested then fires only when it is one of them who is asked), the base branch, the title and labels. Only when I press Run now: a template you keep at hand.

Actions. Prompt a Session: sent right away when the Session is idle, queued behind the running turn when it is busy (through the session's Queue), a stopped Session is resumed first; a Session in error refuses it. For a PR trigger the target can be the Session the PR is attached to, and {pr.url}, {pr.number}, {pr.title}, {pr.repo}, {pr.headSha} and {event} are filled in. New Session: provider, repositories — or, under Environment, a recent snapshot to start each run from instead of cloning (files, tools and repositories come with the image) — the same settings as the New Session form, the first prompt, and Stop the Session when the turn ends (on by default) so boxes do not pile up — the transcript and snapshots stay; for a PR trigger the PR's repository is cloned at the PR head first (from a snapshot: the prompt opens by telling the agent which head to fetch into the snapshot's repository). Auto review: a Session is started on the PR head (a fork's PR is fetched from the base repository, with no connector and no Docker in its box) with a review prompt that treats the PR's description as data, not instructions; when it is done it hands the review to the Control Plane, which posts it under the connected login as one GitHub review (inline comments where the lines are in the diff, the rest in the body) or one Bitbucket comment per finding plus a summary — the box never holds the token. The verdict is capped by Strongest verdict (comment by default, so it never approves or blocks unless you let it), Only what changed since the last review tells the next run on new commits to diff against the last reviewed commit, and Notify me on every review, on findings only, or never. The review names the automation, the run and the head, links back to the Session, and a run whose Session never submits fails. Auto QA (video): a Session on the PR head runs the Auto QA flow against a brief built from the PR (its description, fenced, plus your setup notes: how to start the app, which account), records the cases on the desktop, and the Control Plane posts one comment on the PR — the verdict, one line per case, the Agent's summary — with the video attached on GitHub when this machine's GitHub CLI is 2.99 or newer (a player in the comment), a link to the video otherwise and on Bitbucket; the video is kept by the Control Plane (~/.sessionboxer/qa-videos) so it plays from the Automations and Pull requests pages after the Session is gone. The Agent never fixes, pushes or comments itself; Time limit for the recording (10 minutes) keeps videos short; Comment even when skipped posts when nothing was testable. Attach the PR to its Session: a PR whose branch one of your Sessions pushed shows up in that Session's PRs pane by itself. Notify me: a push notification only.

Limits keep an automation from running away: Sessions at once (2), runs per day (20), runs per PR per day (4), a quiet period after a push before new commits fires (2 minutes; later pushes restart it) and a time limit per run (6 hours). A run past its cap is recorded as skipped with the reason.

Inside a session, Scheduled in the header's ⋯ menu shows the automations that prompt that session (the entry counts them) and lets you add or edit them there; new ones target the session, and the sidebar page still lists them all.

The scheduler lives in the Control Plane, not in the system's cron, so it works the same in sessionboxer service, Docker Compose and the desktop app, and the page can show what happened. Run now runs an automation on the spot, on or off (one that needs a pull request is run from the PR instead). History lists the last 500 runs with the trigger (schedule, catch-up, manual or the PR event), status, duration, the PR, what was done, the error if any, the review or QA result and a link to the Session; #/automations/<id> opens one with its history. A run counts as finished when the turn ends (its verification and anything queued behind it included); a failure marks the automation in the list and the sidebar entry, and sends a push notification if you have them on. Scheduled tasks from before 1.5 are automations now, with the same ids; #/schedules lands here.

This chapter is generated from docs/GUIDE.md in the Sessionboxer repository. Found a mistake? Open an issue.