Review a pull request on demand
Use a verified webhook to queue an agent review when a label is added.
Save the script next to the configuration from Installation and run it with Node.js. It receives verified label events and publishes review jobs; the worker runs the agent separately.
What this example covers
Section titled “What this example covers”- WebhooksVerify the delivery and turn the label event into a job.
- Job queues and workersHand the job from the server to a worker process.
- Durable runsSave each task’s output under the job’s
runId. - Tasks and dependenciesFetch, review, then post.
- Typed responsesValidate the agent’s verdict.
- Repository and branchStart the review branch at the pull request’s head commit.
Write the script
Section titled “Write the script”Save the files shown in the tabs in the same directory, next to the outpost.config.ts from Installation. Start the HTTP server with server.ts and the worker with worker.ts. The configuration’s repository is a local clone of the reviewed GitHub repository.
Validate the queue input and verdict, and provide the GitHub operations for your application.
Run the reviewer on the requested commit and publish its verdict through dependent tasks.
Save the workflow state and run the queue worker.
Run the script
Section titled “Run the script”Start the HTTP server and the queue worker in separate terminals. Give the server the webhook secret configured in GitHub; the worker consumes the review jobs it publishes.
Point the repository’s webhook at the server’s /github path through an HTTPS proxy, with the same secret and the “Pull requests” event.
Understand the steps
Section titled “Understand the steps”The runId names the head commit. Adding the label again on the same commit restores the finished run from its checkpoint, so nothing is reviewed or posted twice; a new commit starts a new review.
review returns only .value: checkpoints hold JSON, not the methods of a dispatch result (From a task to a workflow).
Adapt the example
Section titled “Adapt the example”GitLab merge requests
Section titled “GitLab merge requests”Add a /gitlab route with createGitlabWebhook({ signingToken }), which verifies a signed body. labelAdded() also recognizes merge requests: read the head from object_attributes.last_commit.id, the base from object_attributes.target_branch, and list gitlab:<username> actors in reviewers.
A Slack command
Section titled “A Slack command”Add a /slack route with createSlackSource({ signingSecret }) and commandIssued(event, "/review"), whose text names the pull request. Slack carries no commits: publish { repository, number } and let fetch return { base, head } for review to read.
A Redis queue
Section titled “A Redis queue”Replace createSqliteTaskQueue() in the queue configuration with createBullMQTaskQueue() to run the server and workers on separate machines. Several worker machines also need a shared checkpoint store (S3 and R2).
Approve before posting
Section titled “Approve before posting”Insert an approval gate between review and post. The job then completes as paused, with the pending gate in its value; submit the decision to the same run as shown in Job queues and workers.
Limits
Section titled “Limits”- The worker reviews the clone named by
repository; mappull.repositoryto a clone to serve several repositories. - “Do not edit files” is an instruction to the agent. Its review branch is never merged or pushed; delete
outpost/review-*branches when you no longer need them. - A crashed worker can run
postagain: makepostVerdictdeduplicate on its key (Job queues and workers).
API: serveTriggers · createGithubWebhook · labelAdded · createSqliteTaskQueue · runQueueWorker · defineWorkflowJob · defineIsolatedTask · defineJsonResponse.