Skip to content

Pull requests and merging

draft

release writes the pull request’s title and body; Pitwall opens it on GitHub from the ticket’s branch, pitwall/<key>-<number>, or updates the one the branch already has. A ticket that changed several repositories gets one per repository.

Nothing is merged without a person. Merging is always your action, in Pitwall or on GitHub.

On the ticket, the pull request card shows:

  • its state, and once merged, who merged it, the commit and whether its branch was deleted
  • its changed files: click one for its diff
  • its CI, with the commit under review and the checks that failed or are running
  • the review comments waiting or being addressed, each linking to GitHub

Once qa-notes passed, the ticket opens with a summary of what the run was asked to do and what it did. What Pitwall shows of GitHub is up to a minute old, fifteen seconds while CI runs.

Comment on the pull request on GitHub, or submit a review:

You Pitwall
Leave a comment Waits two minutes for more, then runs address-review on everything said since
Submit a review with a verdict or a body Runs address-review at once
Answers on the pull request, once per round: what it will change, what it answered, what needed nothing
Asked for a change Goes back through implement, code-review, qa-code, release and qa-notes, updates the same pull request, and waits again

A review may go five rounds before the run blocks; resuming it gives five more.

  • Only a person’s comments count: a bot’s are never triaged.
  • An edit to a comment already read is not seen. Write a new one.
  • A failing CI sends nothing back on its own: it blocks the merge.

Approve and merge, on the ticket’s pull request card or a Merge item in the inbox. Pitwall squashes the pull request into the default branch as KEY-N: <title> (#<number>), deletes its branch, and the run is done.

The button stays disabled, saying why, while:

  • the manual tests are not submitted
  • a review is being triaged, or a fix promised to a reviewer was not made
  • CI runs or fails
  • GitHub reports a conflict, a protection rule, a draft or a branch behind
  • the repository allows no squash merge, the only way Pitwall merges

Merging needs the GitHub App to have write access to the repository’s contents (Connecting GitHub).

Merging on GitHub works too: Pitwall sees it and ends the run. Closing the pull request on GitHub without merging also ends the run, and keeps its branch.

A run that ends with nothing to merge waits as ready to close. Close run on the ticket finishes its work and frees the project’s slot. Cancel run stops a run that has no open pull request.