布與提交綁定)
RustFS PR 審查提交指南基于 GitHub API 的 Inline Review 發(fā)布與提交綁定【免費下載鏈接】rustfs2.3x faster than MinIO for 4KB object payloads. RustFS is an open-source, S3-compatible high-performance object storage system supporting migration and coexistence with other S3-compatible platforms such as MinIO and Ceph.項目地址: https://gitcode.com/GitHub_Trending/rus/rustfs本文是一篇面向 RustFS 倉庫貢獻者與 AI 審查代理的實操指南圍繞倉庫內 Inline PR Review Submission 參考文檔展開完整講解如何通過 GitHub REST API 將逐行inline評審意見綁定到已審查的提交上并發(fā)布為正式 Review。讀完本文你將掌握內聯(lián)評論的 JSON 載荷結構、gh api --input的提交命令、發(fā)布前對 PR Head 與評審提交的核對流程以及如何與 RustFS 倉庫自身的風險分級、CI 檢查與 PR 生命周期規(guī)則銜接。一、何時使用 Inline Review授權與場景邊界原文檔開篇即設定了一個硬性前提Read only when an inline review is authorized. Recheck the PR head before posting and bind the review to the reviewed commit.這意味著內聯(lián)評審的發(fā)布不是默認動作而是有明確授權邊界的行為RustFS 根目錄 AGENTS.md 明確規(guī)定Inquiry, diagnosis, review, and planning tasks are read-only unless the user explicitly requests changes查詢、診斷、評審與規(guī)劃類任務默認為只讀。因此只有用戶在對話中明確授權發(fā)布/提交評審時才允許向 GitHub 寫入 Review。技能說明 pr-review/SKILL.md 進一步細化普通評審請求是只讀的除非對話同時授權了發(fā)布posting或修復fixes已給出的授權可以復用無需反復詢問但在請求缺失的發(fā)布許可之前應當先把已授權的評審結果準備好。任何技能或參考文檔本身都不能擴大用戶請求的范圍或授予授權AGENTS.md。在授權成立后Inline Review 適用于需要在特定代碼行上逐條指出問題的場景——例如某個函數(shù)在某一行可能觸發(fā)并發(fā)競爭、某個配置項在具體行上語義錯誤等。若評審結論只是整體性意見而不涉及具體行號則更適合使用gh pr review --comment/--approve/--request-changes這類整體評審方式詳見第五節(jié)。二、發(fā)布在整體流程中的位置pr-review 技能七步工作流posting.md是 pr-review 技能 的配套參考屬于其第 6 步Post the review的專項展開。完整工作流如下步驟動作關鍵命令 / 產物1收集 PR 上下文gh pr view N --repo owner/repo --json ...、gh pr diff ... --name-only2拉取 diff 并按風險分級git fetch remote baseRef refs/pull/N/head、git diff baseRefOid...headRefOid --stat3分組評審變更行為按功能域追蹤調用方與不變量產出帶file:line的 finding4檢查 CI 狀態(tài)gh pr checks N --repo owner/repo5匯總結論輸出 P0–P3 分級 findings 與 verdictAPPROVE/REQUEST_CHANGES/COMMENT6發(fā)布評審整體評審用gh pr review --body-file行內評審用本文的gh api --input7跟進處理按 PR 生命周期 處理后續(xù)變更風險分級決定了評審形態(tài)adversarial-validation.md文檔/注釋類為Exempt重命名、測試/工具鏈改動為Mechanical跑正確性與簡潔性視角局部行為變更為Standard涉及鎖、糾刪碼/仲裁/自愈、復制、multipart、RPC、生命周期/分層、持久化/fsync、IAM/KMS/認證、密碼學、磁盤/線上格式、S3 可見語義的為High risk需要兩個獨立評審者分工或兩次獨立串行 pass。風險分級結果要一并寫進最終評審總結。三、發(fā)布前的關鍵校驗刷新 PR Head 并綁定評審提交原文檔強調兩個發(fā)布前置動作二者缺一不可Recheck the PR head重新核對 PR Head發(fā)布前必須重新拉取并確認 PR 當前 head 仍是評審時使用的那個提交。技能工作流第 2 步要求記錄確切的 base/head若拉取過程中任一引用發(fā)生移動必須先刷新快照再評審SKILL.md。Bind the review to the reviewed commit把評審綁定到被審提交載荷中的commit_id必須填寫實際被評審的 head SHA即reviewed-head-sha而不是當時看起來最新的引用。這與 GitHub Review API 的語義一致Review 是附著在具體 commit 上的評論的行號以該 commit 的 diff 為準。若核對發(fā)現(xiàn) head 已變化正確做法是先評審增量delta再更新 verdict最后才發(fā)布SKILL.md。絕不能把舊結論貼到新提交上也不能用未重新拉取的origin/pull/N/head引用作為證據(jù)SKILL.md。四、Inline 評論的 JSON 載荷結構原文檔給出了完整的請求體示例這是整份參考的核心逐字段說明如下字段類型說明commit_idstring被評審的 head 提交 SHAreviewed-head-sha用于把整個 Review 綁定到該提交bodystringReview 的總體評論文本review bodyeventstring評審結論事件示例為REQUEST_CHANGES同一接口還支持APPROVE與COMMENT與技能中gh pr review的三種模式對應commentsarray行內評論列表每條包含以下三個核心字段comments[].pathstring評論目標文件在倉庫中的路徑如crates/foo/src/bar.rscomments[].lineinteger評論在 PR diff 中對應的行號如42comments[].bodystring該行問題的具體描述finding description完整請求體原樣繼承自 posting.mdcat /tmp/pr_review.json EOF { commit_id: reviewed-head-sha, body: review body, event: REQUEST_CHANGES, comments: [ { path: crates/foo/src/bar.rs, line: 42, body: finding description } ] } EOF gh api --method POST /repos/{owner}/{repo}/pulls/N/reviews --input /tmp/pr_review.json使用要點line必須是該 commit diff 中實際存在的行否則接口會報錯或產生無效定位多行評論場景可進一步使用start_line/side等字段單行場景下pathlinebody即可滿足大部分訴求。comments與commit_id是配套的行號語義依賴提交因此刷新 head 后若提交變化所有行號都必須重新核對這正是先核對、后發(fā)布的原因。body中的總評文字應遵循 RustFS 倉庫約定源注釋、提交、PR 標題與 PR body 均使用英文pull-requests.md即使對話語言是中文評審內容也應保持英文SKILL.md。五、發(fā)布命令為什么必須用--input而不是--body原文檔的提交命令使用gh api --method POST ... --input /tmp/pr_review.json這一選擇與倉庫的硬性規(guī)范完全一致SKILL.md 明確要求Always use--body-fileor--input, never inline multiline--body——多行內容一律通過文件傳入禁止在命令行內聯(lián)多行--body以避免 shell 轉義與換行符被破壞。pull-requests.md 規(guī)定PR/Issue/Discussion 內容中不得出現(xiàn)字面量\n序列也不得包含本地絕對路徑或工具特定標簽/前綴heredoc 寫文件的方式天然規(guī)避了這兩類問題。因此cat /tmp/pr_review.json EOF ... EOF這一步不是可有可無的鋪墊而是保證載荷完整性的標準姿勢先落盤、再以--input上傳。對于不需要行內定位的整體評審同一授權下可使用 CLI 封裝命令SKILL.md# 請求變更 gh pr review N --repo owner/repo --request-changes --body-file /tmp/pr_review.md # 批準 gh pr review N --repo owner/repo --approve --body-file /tmp/pr_review.md # 僅評論不下結論 gh pr review N --repo owner/repo --comment --body-file /tmp/pr_review.md六、寫什么內容Finding 的證據(jù)標準與風險分級發(fā)布只是最后一公里行內評論的內容質量由倉庫的證據(jù)標準約束每個 finding 必須給出具體的失敗場景 file:line沒有問題時直接給出No findings即可——沒有 finding 配額No findings是完整結論AGENTS.md。報告候選 finding 前應先檢查調用方、不變量與既有測試排除能證偽它的證據(jù)缺失的必需測試屬于驗證缺口不能當作運行時缺陷來報AGENTS.md?？蛇x風格偏好、重構建議不應塞進缺陷 finding除非用戶明確要求該評審視角AGENTS.md。High-risk PR 需要在 PR body 中為每個覆蓋的視角記錄一條簡潔 verdictAGENTS.md。因此comments[].body的推薦寫法是file:line 位置 觸發(fā)條件與失敗場景 建議修復三段式例如crates/foo/src/bar.rs:42處在并發(fā)路徑上未加鎖可能觸發(fā)什么競爭、何種輸入可復現(xiàn)、應如何修復。七、發(fā)布之后線程解析與 PR 生命周期行內評論發(fā)布后后續(xù)處理遵循 pull-requests.md 的 PR 生命周期規(guī)則解析線程底層問題修復后才可 resolve review thread若拒絕某條建議需用簡短、基于證據(jù)的理由回復pull-requests.md。跟進監(jiān)控PR 打開后若用戶要求監(jiān)控按事件驅動或有限等待進行只報告狀態(tài)變化、可操作的失敗或顯著延遲后續(xù)要重新拉取新 head并與已記錄的 reviewed SHA 比對重新檢查受影響的調用方與 findingsSKILL.md。更新評審只能在既有授權范圍內更新已發(fā)布的 Review 或 resolve 被指出的線程不得擅自擴大范圍。合并紀律未經(jīng)必需的 reviewer 批準或明確授權絕不合并觀察到合并后驗證提交已到達 base再安全清理任務 worktree/分支pull-requests.md。此外創(chuàng)建/更新 PR 本身的格式要求英文 Conventional Commit 標題、≤72 字符、保留 .github/pull_request_template.md 的全部標題、用--body-file傳多行內容同樣適用于評審后作者側的補丁提交評審者可以在跟進中據(jù)此把關。八、常見陷阱與最佳實踐清單陷阱正確做法未核對 head 就發(fā)布發(fā)布前重新 fetchrefs/pull/N/head并與已記錄 SHA 比對commit_id未綁定被審提交填入實際評審的reviewed-head-sha而非當前最新引用line不在該 commit 的 diff 中行號必須存在于commit_id對應 diffhead 變動后全部重新核對命令行內聯(lián)多行--body一律--body-file整體評審或--inputAPI 載荷內容含字面量\n、本地絕對路徑使用 heredoc 寫文件保持內容純凈pull-requests.md無授權就發(fā)布發(fā)布僅限被明確授權時執(zhí)行技能與參考文檔本身不授予發(fā)布權無證據(jù)的 style nit 湊數(shù)沒有問題時輸出No findingsfinding 必須帶file:line與失敗場景附錄倉庫內相關文件索引核心參考.agents/skills/pr-review/references/posting.md本文主體技能工作流.agents/skills/pr-review/SKILL.md七步流程、發(fā)布與跟進Git 與 PR 規(guī)則.agents/references/pull-requests.md生命周期、--body-file、線程解析風險分級與評審形態(tài).agents/references/adversarial-validation.md倉庫總則AGENTS.md授權邊界、finding 證據(jù)標準、驗證分級PR 模板.github/pull_request_template.mdRelated Issues / Summary / Verification / Impact 四段式GitHub 工作流細則.github/AGENTS.md--body-file規(guī)范歸屬、actionlint 門禁按上述流程操作即可在 RustFS 倉庫中穩(wěn)定、合規(guī)地完成先核對 head、綁定提交、JSON 落盤、gh api --input發(fā)布的完整 Inline PR Review 提交鏈路?！久赓M下載鏈接】rustfs2.3x faster than MinIO for 4KB object payloads. RustFS is an open-source, S3-compatible high-performance object storage system supporting migration and coexistence with other S3-compatible platforms such as MinIO and Ceph.項目地址: https://gitcode.com/GitHub_Trending/rus/rustfs創(chuàng)作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考 RustFS PR 審查提交指南：基于 GitHub API 的 Inline Review 發(fā)布與提交綁定
RustFS PR 審查提交指南基于 GitHub API 的 Inline Review 發(fā)布與提交綁定【免費下載鏈接】rustfs2.3x faster than MinIO for 4KB object payloads. RustFS is an open-source, S3-compatible high-performance object storage system supporting migration and coexistence with other S3-compatible platforms such as MinIO and Ceph.項目地址: https://gitcode.com/GitHub_Trending/rus/rustfs本文是一篇面向 RustFS 倉庫貢獻者與 AI 審查代理的實操指南圍繞倉庫內 Inline PR Review Submission 參考文檔展開完整講解如何通過 GitHub REST API 將逐行inline評審意見綁定到已審查的提交上并發(fā)布為正式 Review。讀完本文你將掌握內聯(lián)評論的 JSON 載荷結構、gh api --input的提交命令、發(fā)布前對 PR Head 與評審提交的核對流程以及如何與 RustFS 倉庫自身的風險分級、CI 檢查與 PR 生命周期規(guī)則銜接。一、何時使用 Inline Review授權與場景邊界原文檔開篇即設定了一個硬性前提Read only when an inline review is authorized. Recheck the PR head before posting and bind the review to the reviewed commit.這意味著內聯(lián)評審的發(fā)布不是默認動作而是有明確授權邊界的行為RustFS 根目錄 AGENTS.md 明確規(guī)定Inquiry, diagnosis, review, and planning tasks are read-only unless the user explicitly requests changes查詢、診斷、評審與規(guī)劃類任務默認為只讀。因此只有用戶在對話中明確授權發(fā)布/提交評審時才允許向 GitHub 寫入 Review。技能說明 pr-review/SKILL.md 進一步細化普通評審請求是只讀的除非對話同時授權了發(fā)布posting或修復fixes已給出的授權可以復用無需反復詢問但在請求缺失的發(fā)布許可之前應當先把已授權的評審結果準備好。任何技能或參考文檔本身都不能擴大用戶請求的范圍或授予授權AGENTS.md。在授權成立后Inline Review 適用于需要在特定代碼行上逐條指出問題的場景——例如某個函數(shù)在某一行可能觸發(fā)并發(fā)競爭、某個配置項在具體行上語義錯誤等。若評審結論只是整體性意見而不涉及具體行號則更適合使用gh pr review --comment/--approve/--request-changes這類整體評審方式詳見第五節(jié)。二、發(fā)布在整體流程中的位置pr-review 技能七步工作流posting.md是 pr-review 技能 的配套參考屬于其第 6 步Post the review的專項展開。完整工作流如下步驟動作關鍵命令 / 產物1收集 PR 上下文gh pr view N --repo owner/repo --json ...、gh pr diff ... --name-only2拉取 diff 并按風險分級git fetch remote baseRef refs/pull/N/head、git diff baseRefOid...headRefOid --stat3分組評審變更行為按功能域追蹤調用方與不變量產出帶file:line的 finding4檢查 CI 狀態(tài)gh pr checks N --repo owner/repo5匯總結論輸出 P0–P3 分級 findings 與 verdictAPPROVE/REQUEST_CHANGES/COMMENT6發(fā)布評審整體評審用gh pr review --body-file行內評審用本文的gh api --input7跟進處理按 PR 生命周期 處理后續(xù)變更風險分級決定了評審形態(tài)adversarial-validation.md文檔/注釋類為Exempt重命名、測試/工具鏈改動為Mechanical跑正確性與簡潔性視角局部行為變更為Standard涉及鎖、糾刪碼/仲裁/自愈、復制、multipart、RPC、生命周期/分層、持久化/fsync、IAM/KMS/認證、密碼學、磁盤/線上格式、S3 可見語義的為High risk需要兩個獨立評審者分工或兩次獨立串行 pass。風險分級結果要一并寫進最終評審總結。三、發(fā)布前的關鍵校驗刷新 PR Head 并綁定評審提交原文檔強調兩個發(fā)布前置動作二者缺一不可Recheck the PR head重新核對 PR Head發(fā)布前必須重新拉取并確認 PR 當前 head 仍是評審時使用的那個提交。技能工作流第 2 步要求記錄確切的 base/head若拉取過程中任一引用發(fā)生移動必須先刷新快照再評審SKILL.md。Bind the review to the reviewed commit把評審綁定到被審提交載荷中的commit_id必須填寫實際被評審的 head SHA即reviewed-head-sha而不是當時看起來最新的引用。這與 GitHub Review API 的語義一致Review 是附著在具體 commit 上的評論的行號以該 commit 的 diff 為準。若核對發(fā)現(xiàn) head 已變化正確做法是先評審增量delta再更新 verdict最后才發(fā)布SKILL.md。絕不能把舊結論貼到新提交上也不能用未重新拉取的origin/pull/N/head引用作為證據(jù)SKILL.md。四、Inline 評論的 JSON 載荷結構原文檔給出了完整的請求體示例這是整份參考的核心逐字段說明如下字段類型說明commit_idstring被評審的 head 提交 SHAreviewed-head-sha用于把整個 Review 綁定到該提交bodystringReview 的總體評論文本review bodyeventstring評審結論事件示例為REQUEST_CHANGES同一接口還支持APPROVE與COMMENT與技能中gh pr review的三種模式對應commentsarray行內評論列表每條包含以下三個核心字段comments[].pathstring評論目標文件在倉庫中的路徑如crates/foo/src/bar.rscomments[].lineinteger評論在 PR diff 中對應的行號如42comments[].bodystring該行問題的具體描述finding description完整請求體原樣繼承自 posting.mdcat /tmp/pr_review.json EOF { commit_id: reviewed-head-sha, body: review body, event: REQUEST_CHANGES, comments: [ { path: crates/foo/src/bar.rs, line: 42, body: finding description } ] } EOF gh api --method POST /repos/{owner}/{repo}/pulls/N/reviews --input /tmp/pr_review.json使用要點line必須是該 commit diff 中實際存在的行否則接口會報錯或產生無效定位多行評論場景可進一步使用start_line/side等字段單行場景下pathlinebody即可滿足大部分訴求。comments與commit_id是配套的行號語義依賴提交因此刷新 head 后若提交變化所有行號都必須重新核對這正是先核對、后發(fā)布的原因。body中的總評文字應遵循 RustFS 倉庫約定源注釋、提交、PR 標題與 PR body 均使用英文pull-requests.md即使對話語言是中文評審內容也應保持英文SKILL.md。五、發(fā)布命令為什么必須用--input而不是--body原文檔的提交命令使用gh api --method POST ... --input /tmp/pr_review.json這一選擇與倉庫的硬性規(guī)范完全一致SKILL.md 明確要求Always use--body-fileor--input, never inline multiline--body——多行內容一律通過文件傳入禁止在命令行內聯(lián)多行--body以避免 shell 轉義與換行符被破壞。pull-requests.md 規(guī)定PR/Issue/Discussion 內容中不得出現(xiàn)字面量\n序列也不得包含本地絕對路徑或工具特定標簽/前綴heredoc 寫文件的方式天然規(guī)避了這兩類問題。因此cat /tmp/pr_review.json EOF ... EOF這一步不是可有可無的鋪墊而是保證載荷完整性的標準姿勢先落盤、再以--input上傳。對于不需要行內定位的整體評審同一授權下可使用 CLI 封裝命令SKILL.md# 請求變更 gh pr review N --repo owner/repo --request-changes --body-file /tmp/pr_review.md # 批準 gh pr review N --repo owner/repo --approve --body-file /tmp/pr_review.md # 僅評論不下結論 gh pr review N --repo owner/repo --comment --body-file /tmp/pr_review.md六、寫什么內容Finding 的證據(jù)標準與風險分級發(fā)布只是最后一公里行內評論的內容質量由倉庫的證據(jù)標準約束每個 finding 必須給出具體的失敗場景 file:line沒有問題時直接給出No findings即可——沒有 finding 配額No findings是完整結論AGENTS.md。報告候選 finding 前應先檢查調用方、不變量與既有測試排除能證偽它的證據(jù)缺失的必需測試屬于驗證缺口不能當作運行時缺陷來報AGENTS.md?？蛇x風格偏好、重構建議不應塞進缺陷 finding除非用戶明確要求該評審視角AGENTS.md。High-risk PR 需要在 PR body 中為每個覆蓋的視角記錄一條簡潔 verdictAGENTS.md。因此comments[].body的推薦寫法是file:line 位置 觸發(fā)條件與失敗場景 建議修復三段式例如crates/foo/src/bar.rs:42處在并發(fā)路徑上未加鎖可能觸發(fā)什么競爭、何種輸入可復現(xiàn)、應如何修復。七、發(fā)布之后線程解析與 PR 生命周期行內評論發(fā)布后后續(xù)處理遵循 pull-requests.md 的 PR 生命周期規(guī)則解析線程底層問題修復后才可 resolve review thread若拒絕某條建議需用簡短、基于證據(jù)的理由回復pull-requests.md。跟進監(jiān)控PR 打開后若用戶要求監(jiān)控按事件驅動或有限等待進行只報告狀態(tài)變化、可操作的失敗或顯著延遲后續(xù)要重新拉取新 head并與已記錄的 reviewed SHA 比對重新檢查受影響的調用方與 findingsSKILL.md。更新評審只能在既有授權范圍內更新已發(fā)布的 Review 或 resolve 被指出的線程不得擅自擴大范圍。合并紀律未經(jīng)必需的 reviewer 批準或明確授權絕不合并觀察到合并后驗證提交已到達 base再安全清理任務 worktree/分支pull-requests.md。此外創(chuàng)建/更新 PR 本身的格式要求英文 Conventional Commit 標題、≤72 字符、保留 .github/pull_request_template.md 的全部標題、用--body-file傳多行內容同樣適用于評審后作者側的補丁提交評審者可以在跟進中據(jù)此把關。八、常見陷阱與最佳實踐清單陷阱正確做法未核對 head 就發(fā)布發(fā)布前重新 fetchrefs/pull/N/head并與已記錄 SHA 比對commit_id未綁定被審提交填入實際評審的reviewed-head-sha而非當前最新引用line不在該 commit 的 diff 中行號必須存在于commit_id對應 diffhead 變動后全部重新核對命令行內聯(lián)多行--body一律--body-file整體評審或--inputAPI 載荷內容含字面量\n、本地絕對路徑使用 heredoc 寫文件保持內容純凈pull-requests.md無授權就發(fā)布發(fā)布僅限被明確授權時執(zhí)行技能與參考文檔本身不授予發(fā)布權無證據(jù)的 style nit 湊數(shù)沒有問題時輸出No findingsfinding 必須帶file:line與失敗場景附錄倉庫內相關文件索引核心參考.agents/skills/pr-review/references/posting.md本文主體技能工作流.agents/skills/pr-review/SKILL.md七步流程、發(fā)布與跟進Git 與 PR 規(guī)則.agents/references/pull-requests.md生命周期、--body-file、線程解析風險分級與評審形態(tài).agents/references/adversarial-validation.md倉庫總則AGENTS.md授權邊界、finding 證據(jù)標準、驗證分級PR 模板.github/pull_request_template.mdRelated Issues / Summary / Verification / Impact 四段式GitHub 工作流細則.github/AGENTS.md--body-file規(guī)范歸屬、actionlint 門禁按上述流程操作即可在 RustFS 倉庫中穩(wěn)定、合規(guī)地完成先核對 head、綁定提交、JSON 落盤、gh api --input發(fā)布的完整 Inline PR Review 提交鏈路?！久赓M下載鏈接】rustfs2.3x faster than MinIO for 4KB object payloads. RustFS is an open-source, S3-compatible high-performance object storage system supporting migration and coexistence with other S3-compatible platforms such as MinIO and Ceph.項目地址: https://gitcode.com/GitHub_Trending/rus/rustfs創(chuàng)作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考