settle-effort

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Settle Effort

Approving the pull request is the user's last step. Everything after it is yours.

批准 pull request 是用户最后需要完成的步骤。此后的一切都由你负责。

Flow

流程

Find the effort: the pull request, its branch, spec, tickets and handoff, and every worktree and branch the build left behind, delegates' leftovers included.
- From a checkout that isn't on the effort's branch: list pull requests by head branch with
```
gh pr list --head
```
  and
```
--state all
```
  , since without
```
--state all
```
  a merged pull request doesn't show.
Merge the pull request once its checks pass, and check that the default branch's CI passes after the merge. Merge with
```
gh pr merge
```
and the project's usual method, and leave out
```
--delete-branch
```
: it deletes branches before they are proven merged, and switches the current checkout to the default branch.
- When the session has the session-status tool: before merging, raise its open
```
before_settling
```
  and
```
blocked
```
  decisions as
```
/settle-session
```
  's "Nothing undecided" step says, since an answer can change the merge.
- When the spec says "QA: blocking": merge only once every QA ticket is closed. Until then, tell the user which ones are still open and stop the settle there; it resumes once they're closed.
- When the default branch's CI fails after the merge: stop before step 5, tell the user what failed, and file or fix it as they decide.
- After a squash or a rebase: check that anything pinned to one of the branch's commits, such as an image URL with a commit SHA, still resolves, since the default branch doesn't hold those commits.
- When the pull request is already merged: skip the merge, and still check the default branch's CI and, after a squash or a rebase, the pinned commits.
Read the pull request's description and the handoff for what the delivery left open: follow-ups, checks it skipped and decisions for the user.
Run every follow-up and skipped check from step 3, such as installing what changed or trying what could only be tried after the merge, and note each result for the report.
Carry unfinished work over as tickets in the next effort, labelled for it and linked back to where each came from.
```
gh issue create --label
```
fails when the label doesn't exist yet, so create a missing
```
effort:
```
label first with
```
gh label create
```
. Then close the spec and every ticket the merge finished, by hand for any a "closes" keyword missed.
- When it isn't clear which effort is next: ask the user.
- For QA tickets: leave them open for the user, with a comment on how to reach the build.
Settle the session with
```
/settle-session
```
, naming every worktree and branch from step 1 for cleanup assessment. Keep the caller and terminal topology open; release only the proven-merged, unoccupied worktrees that qualify under
```
/settle-session
```
. Have its report also say what merged, what closed, what carried over and what each follow-up from step 4 showed.

查找 effort： 找到其 pull request、branch、spec、tickets 和 handoff，以及构建过程留下的所有 worktree 和 branch，其中也包括 delegates 的遗留内容。
- 当当前 checkout 不在 effort 的 branch 上时： 使用
```
gh pr list --head
```
  和
```
--state all
```
  按 head branch 列出 pull requests，因为不加
```
--state all
```
  时，已经合并的 pull request 不会显示。
合并 pull request：待其 checks 通过后执行合并，并确认合并后 default branch 的 CI 也能通过。使用
```
gh pr merge
```
和项目惯用的方式合并，且不要添加
```
--delete-branch
```
：该选项会在 branch 被证明已合并前将其删除，并把当前 checkout 切换到 default branch。
- 当 session 拥有 session-status tool 时： 在合并前，按照
```
/settle-session
```
  的 "Nothing undecided" 步骤，提出其尚未处理的
```
before_settling
```
  和
```
blocked
```
  决策，因为答复可能影响合并。
- 当 spec 中写着 "QA: blocking" 时： 仅在所有 QA tickets 均已关闭后合并。在此之前，告诉用户哪些 tickets 仍未关闭，并在此停止 settle；待它们关闭后再继续。
- 当合并后 default branch 的 CI 失败时： 在步骤 5 之前停止，告诉用户失败内容，并由用户决定是创建 issue 还是进行修复。
- 执行 squash 或 rebase 后： 检查任何固定到该 branch 某个 commit 上的内容（例如带 commit SHA 的 image URL）是否仍能正确解析，因为 default branch 并不包含那些 commits。
- 当 pull request 已经合并时： 跳过合并，但仍要检查 default branch 的 CI，并在 squash 或 rebase 后检查被固定的 commits。
读取 pull request 的描述和 handoff，确认此次交付遗留了哪些开放事项：follow-ups、跳过的 checks，以及需要用户作出的 decisions。
执行步骤 3 中的每一项 follow-up 和被跳过的 check，例如安装发生变更的内容，或尝试只有在合并后才能尝试的操作，并在报告中记录每项结果。
结转未完成的工作，在下一个 effort 中将其创建为 tickets，为其添加对应的 label，并链接回各自的来源。
```
gh issue create --label
```
在 label 尚不存在时会失败，因此先用
```
gh label create
```
创建缺失的
```
effort:
```
label。然后关闭 spec，以及合并工作已完成的每个 ticket；如果有 ticket 未被 "closes" 关键词自动关闭，则手动关闭。
- 无法确定下一个 effort 时： 询问用户。
- 对于 QA tickets： 为用户保留 open 状态，并添加评论说明如何访问该 build。
结束 session，使用
```
/settle-session
```
，并列出步骤 1 中的每个 worktree 和 branch，供清理评估。保持调用方（caller）和终端拓扑（terminal topology）处于开放状态；仅释放已证明合并、未被占用且符合
```
/settle-session
```
条件的 worktrees。让其报告同时说明合并了什么、关闭了什么、结转了什么，以及步骤 4 中的每项 follow-up 显示了什么结果。