Previews
Previews
While working, the agent can stand up a live preview of a static site the Task changes, on your cloud, and check that it loads. The pull request lists each preview's URL so a reviewer can open it.
How the preview is built depends on the site:
- A static site Deployment.io deploys — Deployment.io builds the preview from the agent's work the same way the deployment builds it, using its build command, root directory and publish directory.
- Another repository — Deployment.io detects how to build it and builds it the same way. It recognises Vite, Create React App, Vue CLI, Astro, Gatsby, SvelteKit with its static adapter, and Next.js with static export. When it can't tell how, the agent builds the site itself.
A preview is removed after a period without use, and when its Task is deleted.
Preview configuration
Previews Deployment.io builds use your organization's Preview configuration: variables and secret files set in Org Settings → Agents → QA.
A preview runs a Task's code before anyone has reviewed it, so add only values meant for previews — test-mode keys, sandbox endpoints and the public settings the build needs. Never add staging or production secrets.
Stored values are never shown again; to change one, enter a new value. The agent never sees these values.
QA on a preview
After the Review stage, Deployment.io checks the change in a running site. For each repository with a static site Deployment.io can build — one it deploys, or one it can detect how to build, the same rules as the previews above — it builds a preview, and a QA agent checks that preview in a real browser, at desktop, tablet and phone sizes as a criterion needs.
QA is advisory: it never holds the pull request. What it finds is reported on the pull request, and you decide what to do about it.
What it checks
QA checks each of the Task's acceptance criteria and reports it as passed, failed, or not checked with a reason. The criteria come from the Acceptance criteria box when you create or edit a Task, or from the session's spec for a Task converted from an Assistant session — see Creating and Running a Task. QA checks only these; it never picks criteria out of the description.
A Task with no acceptance criteria gets a smoke check instead: the preview loads with no page errors and no failed requests to the site itself.
A criterion comes back not checked when QA can't check it by looking at the site — for example, one that needs a sign-in. When QA runs again on production after a merge, a criterion that can only be checked by changing data is not checked either; see Deploy After Merge.
What it builds
The preview QA checks is built from the change merged with the latest commit of the base branch, in a throwaway copy. Nothing is pushed, and the pull request gets no merge commit. That way QA checks what you'd get after merging, not a branch that may be behind.
If the change and the base branch don't merge cleanly, QA checks the branch as built and the pull request says why.
When a criterion fails
If a criterion fails, the agent gets one round to fix it. The fix is reviewed, and QA checks once more. Anything still failing is listed on the pull request.
In the pull request
The pull request's description has a line that sums up the result, one of:
- "QA on a preview: <n> of <m> acceptance criteria passed", followed by " · <k> not checked" and " · <j> fixed before this PR" when they apply
- "no acceptance criteria — checked the preview loads"
- "skipped — no static site in this change"
- "couldn't run — <reason>"
Below it, a QA on a preview section lists the failed criteria and the problems found, with collapsed lists for Not checked, Fixed by QA and Observations. A line per repository says what QA checked:
- "QA checked <repository> merged with <base branch> at <short commit>."
- "QA checked <repository>'s branch as built: <reason>."
Choosing the QA model
QA uses the Task's QA model, which you can pick when you create, start or re-run the Task. By default it's the same as the reviewer's model.