Project setup
PRs opened outside Soffi
Not every pull request starts in Soffi. Engineers still open branches from their editors, and those pull requests deserve the same live review. Soffi comments on them with a link that opens the pull request in Soffi, so anyone on the team can see it running without pulling the branch.
SoffiBot's comment
When a pull request is opened in a repository connected to Soffi, SoffiBot, Soffi's GitHub App, posts a Soffi AI Summary comment. The summary of the changes and their commits is folded away so it doesn't crowd the conversation; the one line left visible is a link, and what it says depends on where the repository's Project stands:
| The link says | When |
|---|---|
| Deploy in Soffi | The repository belongs to a published Project. |
| Open this project in Soffi, with a note that publishing turns on PR previews for everyone | The Project is deployed but not published yet. |
| Finish setting up in Soffi | The Project is still being set up. |
| Create a Soffi project | The repository isn't part of any Project. |
Pull requests that came from a Soffi Workspace get Edit in Soffi instead, which opens the Workspace they came from.
Turn the comment off
If you'd rather SoffiBot didn't comment on your pull requests, an Admin can switch it off. Open Settings, go to GitHub app, and on the Advanced tab turn off AI Summary Comments. It's on by default. Turning it off there stops the comment on every repository; to stop it on just one, open that repository on the Repositories tab and turn it off in its settings. You can turn it back on at any time.
Preview a pull request
Following Deploy in Soffi opens a Workspace for that pull request. There is one per pull request, so following the link again, or a teammate following it, opens the same Workspace. It shows the pull request's version of the code and links back to the pull request on GitHub.
What happens next depends on who opens it first. When an Admin or the Owner follows the link, the Workspace joins the Project and Soffi deploys it as soon as the code is ready. When an Editor does, the Workspace opens without a deployment: its card reads No project, and the Workspace says it isn't deployed and offers to deploy it. Deploying runs the whole app at the pull request's version, with its own preview and Data Twin, and makes the Workspace part of the Project. Editors and above can deploy it. Reviewers can open a pull request's Workspace once someone has created it and read its code, but can't create or deploy one.
Contribute to the pull request
The Workspace works on the pull request's own branch, so it's a place to change the pull request, not just look at it. Edit it the way you would any Workspace, then Ship: Ship pushes your work to the same pull request instead of opening a new one, and the author and reviewers see your commits in the pull request like anyone else's. When the author pushes from their editor, their new commits come into the Workspace on their own, usually within a minute, and the Preview refreshes. Pushes from a fork, or from someone without write access to the repository, wait in Sync status as Update from PR #N needs approval until someone with write access chooses Bring it in. Once the Workspace is part of the Project, it brings in updates from the Project as well. See Staying up to date and From Workspace to pull request.
The pull request's Workspace stays separate from everyone else's work. A Workspace someone starts in the Project is built from the Project's setup, never from an open pull request.
When the pull request merges or closes
When the pull request is merged or closed on GitHub, its Workspace has done its job. Any deployment it has stops, and the Workspace is archived. Opening it afterwards says whether it was archived because the pull request merged or because it closed, and offers the pull request on GitHub.