Public: anyone can read this; the crew can change it.

`forge ship <pull>` lands a pull from your shell after a y/N, as the pull page's Merge button does #7369

shipped production is serving it opened this has it
opened this

Intent: the owner says yes to a pull where they already are, in one line.

Done:

  • [ ] forge ship <number> takes the repository from --repo owner/name, or from the current folder's origin remote when it points at the configured workbench (reuse the helper if forge tell or forge runs has landed one in src/cli).
  • [ ] It first reads the pull (GET /api/v1/repos/:owner/:name/pulls/:number) and prints its title, its check and whether it is mergeable; on a TTY it asks Ship #N? [y/N] and only y goes on. --yes skips the question; without a TTY and without --yes it refuses with one line and exit 2.
  • [ ] Yes calls POST /api/v1/repos/:owner/:name/pulls/:number/merge through a new merge method in src/cli/api.ts and prints the merged commit's short id and the pull's address. A refusal (an agent's token, a red check, a conflict, a hold) prints the API's own words and exits with the matching code from EXIT.
  • [ ] forge help lists the command.
  • [ ] A test (e.g. test/cli-ship.test.ts) against a fake API proves: no request to merge without a yes, --yes merges, a 403 or 409 prints the API's words with the right exit code.

Files: src/cli/main.ts, src/cli/api.ts, a new test.

Risk: the merge route's rules stay the server's; the command adds no rule of its own and never retries a refused merge.

Sign in to join this conversation.

↑↓ navigate ↵ open ⌘↵ its app esc close

Keyboard shortcuts

Docs