Ship code from a meeting

When a meeting’s project has repositories connected, the meeting is not only where the work is decided. It is also where the change is prepared, reviewed, and published.

What you’ll need

• A project with at least one connected repository, on the project’s Repos tab. A project with none has no delivery pipeline to run.
• Being the project’s owner or one of its approvers, for the last step. Everybody else can watch it.

Which stages need GitHub

The first three stages below are plain git, so they run on any remote a project can reach: the working copy, the branch each agent commits to, and the merge that folds one back into the other.

The fourth is not. A pull request, the review that reads it, and Ship, which merges it, are all GitHub-hosted, so a release needs the GitHub App connected for the project. On a project pointing at a plain git remote the Repositories tab shows the working copy but no View Changes link, and no Release tab appears, because there is no pull request for either to point at.

The four stages

One meeting, one release

Everything below is per meeting. A meeting that touches three repositories prepares three working copies and publishes them in one go, so a change that spans the API and the web client ships as one thing.

1. Repositories

While the meeting is live, the state panel carries a Repositories tab listing every repository the project has connected. Each row shows the repository and whether it already has a working copy for this meeting.

Select Set up on a row to give this meeting a working copy of that repository. That is the branch the meeting’s work collects on, kept separate from your default branch. Once it exists, the row reads Working copy and Active, as above.

2. Branches

Agents do not commit to the working copy directly. Each accepted piece of work runs on a runner, in a real checkout, on a branch of its own named after the task it came from.

The branch is task/ followed by the task’s id, unless the run was given an explicit name. In the sprint check-in, Marcus is fixing the Safari elevation profile as SUM-15, so his run gets the branch for that task, and Rhea’s offline-caching work sits on its own beside it. Two agents changing the same repository in the same meeting never write to the same ref.

3. Merge

When a run is accepted, its branch is merged into the meeting’s working copy, and the row is one change closer to being releasable. Marcus’s task/SUM-15 lands on the meeting’s copy of summitline-app; Rhea’s lands next to it.

The row records it. Under the repository name, a working copy that has collected work reads changes merged followed by the commit it landed as, which is how the screenshot above shows the check-in’s copy carrying e9cc386 from Marcus’s branch. A working copy nothing has merged into yet says only Working copy.

This is ordinary git, done through the same repo seam the working copy uses, so it happens on a plain remote with no forge involved. Two things are worth knowing:

• A conflict is surfaced, never resolved. If the working copy moved under a branch, the merge is reported as failed and the branch is left alone rather than half applied.
• Nothing reaches your default branch here. The meeting’s work accumulates on its own branch until somebody ships it.

4. Release

Once the meeting is finished, the collected work becomes a pull request, and the panel gains a Release tab. The row gains a View Changes link, which opens that pull request on GitHub, and a status of Changes pending underneath the repository name.

The review gate

Each repository with a pull request carries a review chip:

Chip	What it means
Pending Review	Nothing has reviewed the change yet. Review starts one
Review Passed	The review found nothing blocking. Select the chip to read the findings
Review Blocked	The review found something that has to be fixed first

A review is an agent reading the diff against the project’s standards, and it reports counts by severity: critical, high, medium, low.

Ship

Ship Meeting publishes every approved change to its repository. It is enabled only when two things are true:

• Every pull request in the meeting has a passing review. A single blocked review stops the whole release, and the panel says so.
• You are the project’s owner or an approver. Everybody else sees the button disabled with a note saying who can ship.

After shipping, each row shows Published, or Publish Failed if the merge itself was refused (a protected branch, or a conflict).

Where the work itself happens

The meeting is the control surface. The actual editing happens in a run on a runner, inside a workspace that is a real checkout of the repository. To follow an individual change step by step, open the task and its Execution tab rather than watching the meeting.

Next steps

• Workspaces and git: what a runner does with a checkout.
• Runs and attempts: how one change is actually made.
• Meeting summaries: the record of what the meeting decided.