Repository navigation
[RSI Baseline] Close the GitHub Issue-to-Release automation loop #789
Description
Parent Epic: #784
Why
The baseline must demonstrate a real, end-to-end software delivery loop rather than stop after generating a PR.
Scope
- Connect GitHub Issues, branches/PRs, review verdicts, required checks, merge queue, tags and Releases.
- Bind verification/review evidence to the current head SHA; invalidate a verdict when the PR head changes.
- Reuse GitHub Actions, branch protection and merge queue; never bypass repository rules.
- Enforce risk-tier-specific merge/release policy and explicit human approval for configured sensitive actions.
- Generate/validate changelog fragments and release notes; verify published artifacts and report release status.
- Handle failed CI, review changes, merge conflicts, missing workflow runs and partial release failures.
- Keep actions idempotent and reconcile against GitHub live state before retrying.
Acceptance criteria
- A low-risk pilot progresses from Issue through PR, current-SHA verification, required CI, merge queue and a test release.
- Release artifacts and tag/commit association are verified.
- Failures have actionable reasons; retries do not create duplicate PRs/releases.
- No admin merge, gate bypass or implicit production deployment.
Related
- Release cadence: at least one tag per day, small and stable #351 release pipeline
- [RFC] 跨运行时 Agent 对话与协作：以 OpenCode 为首个试点的目标、需求与两种方案 #198 cross-runtime collaboration
- [Team] Persist a minimal collaboration task lifecycle #54 task lifecycle
Bot identity and review separation
The pilot must use a dedicated, least-privilege GitHub automation identity rather than a maintainer's personal token for routine writes.
- Create/update the PR and post automation status using the configured GitHub App or dedicated bot identity.
- Keep the Developer and Reviewer execution contexts separate. A Developer must not be able to manufacture or edit a valid Reviewer verdict merely by writing PR text.
- Bind the review verdict to the exact head SHA and verify it against GitHub's current PR state before enqueueing.
- Continue to rely on required CI checks, repository rules and the merge queue; never bypass them. Verify whether the chosen App identity and repository rules can perform each required operation before enabling live automation.
- Record the actor, operation, target SHA and outcome for each automated write. Keep maintainer-only operations (App installation, permission changes, policy changes and explicitly sensitive releases) behind human authorization.
Acceptance criteria additions
- A low-risk pilot can create and update its PR without a maintainer's personal GitHub credential.
- Reviewer evidence is produced by a separately controlled execution path and cannot be forged by the Developer role.
- App permissions and any operation that still requires a human are documented; no unsupported GitHub permission is assumed.
Activity
Birfy commentedon Oct 22, 2026
Written-by: Triage
enhancement|area:automation|area:release|needs-human. This loop is not greenfield — it ran end to end today without Grok Bot:#779was triaged and madeagent-ready, Dev claimed it and opened#783, Reviewer judged it, andv0.2.4shipped (177d0ffa, tagv0.2.4, release 21:37Z, 39 changelog entries). The pieces are already named and deterministic:.github/workflows/controller.yml,merge-gate.yml,enqueue-guard.mjs,review-gate.mjs,risk-gate.mjs,pass-label.yml,changelog.mjs,release.yml, and.github/agent/.So the honest scope is the gaps the loop still has, not a second pipeline. The three I can name from the live record:
at <sha>) and byreview-gate/merge-gaterefusing a stale one; nothing invalidates the comment when the head moves, so a person reading the PR sees a green verdict next to a newer commit.#765was enqueued at 11:24:48 and dropped at 11:24:58 with the guard's reason swallowed; it then sat for 20 minutes. Today's#793did it right (re-readisInMergeQueuewithin 60 s) because a person did it by hand. That is a rule in the group notice, not a check.maincan be green on the PR and red inmerge_group(#759: 9/9 on the head, red infollow-through.test.js:264). The rerun is the truth and nothing currently reconciles it back onto the issue.To become
agent-ready, pick one of those three and write the check that fails without the fix. The rest of the loop is already there and should be linked, not rebuilt.Birfy commentedon Nov 7, 2026
Written-by: Chief
Cluster note, no new question. Same RSI Baseline cluster question as #784 (asked 2026-11-06T13:11:53Z): A close the cluster as superseded; B keep only #785 and #787 and close the rest. This issue is in the "close" half of option B. Waits on that answer.
Birfy commentedon Nov 7, 2026
Written-by: Chief
Owner decision 2026-11-07 (Asia/Shanghai), option A: the whole RSI cluster is closed.
The epic's goal 2 — Issue → branch → implement → verify → PR → review → CI → merge queue → release — now runs as the daily workflow pipeline; #789's loop is closed in practice and #788's "capability pack" is, in fact, those workflow definitions. What is left here is a second design for a system that already runs, with no bounded diff anyone can verify, and the cluster has not moved since 2026-10-22.
Reopen only if the owner funds the RSI programme; then file a fresh ticket with named files and acceptance criteria rather than reviving this index.
The issue-to-release loop is closed: a PR carries
Fixes #N, the merge queue lands it, the release routine ships a tag daily, and #1209's watchdog checks the beat. This ticket asks for the loop that already runs.