Self serve preview environments for every pull request

By General Input

A board where product, design and QA bring up a clickable running version of any open pull request themselves, without asking an engineer to spin one up.

Integrations

  • Daytona
  • GitHub

Type

App

Categories

  • Engineering
  • Operations

I want a preview environment desk that the non engineers on my team open whenever they need to click through a change before it ships, so product managers, designers and QA stop asking an engineer to spin one up for them. Build it as an app backed by GitHub for the pull requests and Daytona for the environments. There is no trigger anywhere in this app and nothing runs on a schedule: a person opens the board, browses open pull requests, and chooses which one to bring up so they can look at it in a browser. Keep it that way.

Start with a settings view where someone technical registers the repositories the desk covers. Each row holds the GitHub owner and repository name, the install command for that repository, the start command that runs its dev server, and the port that server listens on. Persist these for the whole app so everybody opens the same board and so the person launching never types a shell command. The board only ever shows pull requests from registered repositories, and the launch handler only ever runs commands read from this configuration, never free text entered at launch time.

The main surface is a board of open pull requests across every registered repository. For each repository call List Pull Requests with state open, then call Get a Pull Request per result for the head branch, the changed file count and the additions and deletions, and List Pull Request Reviews to work out where it stands: approved, changes requested, or still waiting on a reviewer. Each row shows the repository, the pull request number and title, the author, the branch, the number of changed files, the review state as a colored label, how long ago it was updated, a link out to the pull request on GitHub, and a Launch button. Give the board a manual refresh control and let people filter by repository and by review state.

Launch runs a server side handler. Before creating anything, call List Sandboxes filtered by the pull request label and enforce one environment per pull request: if an environment already exists for that pull request, do not create a second one, just take the person to the link that already exists and say who launched it. Otherwise call Create Sandbox with public set to true, which is required for the preview URL to be reachable without a Daytona login, and attach labels recording the repository, the pull request number, the name of the person who launched it and the launch timestamp. Sandbox creation is asynchronous and comes back in a creating state, so poll Get Sandbox until the state is started before making any call that runs inside it.

Once the sandbox reports started, call Set Auto-Stop / Auto-Archive / Auto-Delete Intervals straight away with a short window so a forgotten environment shuts itself down without anyone remembering to, for example stop after thirty minutes of inactivity, archive soon after, and delete within a day. Then call Git Clone Repository to pull in the pull request head branch, Create Session for a persistent shell, and Execute Command in Session to run the stored install command and wait for it to finish. Run the stored start command through Execute Command in Session as well, using the async option, so the long running dev server keeps running after the call returns rather than being killed when a synchronous command completes. Finally call Get Sandbox Preview URL for the configured port and show a clickable link the moment it is ready.

Show real progress while a launch is in flight, stepping through creating the environment, pulling the branch, installing, starting and waiting for the port, because this takes long enough that silence reads as failure. If the install or start command exits non zero, show the actual command output in the app rather than a generic error message, and offer a Tear Down button right there so a broken attempt does not sit around consuming quota. If Daytona returns a quota error because too many environments are already running, say so plainly and point at the live section.

Above the pull request list, keep a live section showing which pull requests currently have an environment up. Rebuild this section from List Sandboxes filtered by the label rather than from anything held in app state, so it survives a page refresh and correctly shows environments other people launched. Each live row shows the repository and pull request title, who launched it, how long it has been running, the preview link, and a Tear Down button wired to Delete Sandbox with a confirmation step. If a sandbox exists whose labels point at a pull request that has since been merged or closed, flag it in the live section as safe to tear down.

Give each live environment a Post link to the pull request action that uses Create an Issue Comment to drop the preview link onto the pull request itself, so reviewers find it in context. Make it a deliberate button someone presses rather than something that fires on every launch, and have the comment name the person who launched the environment and mention that the link stops working once the environment shuts down.

Related prompts

Explore more prompts
Open a Heroku release war room the moment production looks wrongSee what Hacker News really thinks of the tools in your stackSee and fix Terraform variable drift across every workspaceA docs coverage board that catches what shipped undocumentedA technology radar board your architecture group works out ofTake-home review desk that runs candidate code in a sandboxDeploy control room for DigitalOcean App Platform appsClean up the Fly.io preview apps your team left behindFind the dbt models that are burning your warehouse budgetTranslation coverage board for your app's language files