fix: 自动安装 Webhook、修正 PR 审查范围与分支匹配语义

三个导致「提交了新 PR 但没有任何反应」的独立问题:

1. 从不创建 Webhook
   服务只被动接收事件,但配置仓库时不会去 Gitea 里建 Webhook,
   结果仓库永远收不到 push / PR 事件,看起来和坏掉一样。
   - 保存仓库时自动创建或更新 Webhook(POST /repos 返回值带 webhook 结果)
   - 新增 GET/POST /api/repos/:id/webhook 查询与修复
   - 仓库列表新增 Webhook 列,未配置可一键「修复 Webhook」
   - 新增 CR_WEBHOOK_URL,留空则推导为「Gitea 主机名 + 本服务端口」

2. 审查范围用了错的分支做基准
   resolveRange 优先取 managed_branch 而不是 job.base_ref,
   于是 PR 被拿去和一个无关分支比较;当两者内容相同就报
   「base and head resolve to the same commit」直接跳过。
   改为优先用该改动实际要合入的分支(PR 的目标分支),
   仅 push 事件回退到 managed_branch。

3. 检查分支的匹配语义反了
   原先要求 PR 的 head(功能分支)出现在 check_branches 里,
   而用户配置的是「要保护的目标分支」(如 prd/test),
   功能分支永远不会被列出,所以 PR 一律被过滤掉。
   新增 pullRequestMatches:PR 的 base 命中检查分支即审查,
   head 命中仍保留支持。这样「审查所有合入 prd/test 的改动」成立。

验证:PR offerpai/offerpai_h5#2 重跑通过,7 条内联评论、
2 条阻断、commit status failure、Issue #3 创建。
This commit is contained in:
2026-09-20 14:44:26 +08:00
parent 6dc77ce907
commit 34f2897888
6 changed files with 208 additions and 22 deletions
+31
View File
@@ -120,6 +120,37 @@ export class GiteaClient {
return out;
}
async listRepoWebhooks(owner, repo) {
return this.get(`/api/v1/repos/${owner}/${repo}/hooks`);
}
/**
* Create (or update) the review webhook for a repository.
* Returns { created: boolean, id }.
*/
async ensureRepoWebhook(owner, repo, { url, secret, events = ["push", "pull_request"] }) {
const desired = {
type: "gitea",
active: true,
name: "gitea-codereview",
events,
config: { url, content_type: "json", ...(secret ? { secret } : {}) },
};
let existing = [];
try {
existing = (await this.listRepoWebhooks(owner, repo)) ?? [];
} catch {
existing = [];
}
const match = existing.find((h) => h.config?.url === url) ?? existing.find((h) => h.name === desired.name);
if (match) {
await this.patch(`/api/v1/repos/${owner}/${repo}/hooks/${match.id}`, desired);
return { created: false, id: match.id };
}
const created = await this.post(`/api/v1/repos/${owner}/${repo}/hooks`, desired);
return { created: true, id: created?.id ?? null };
}
/** Create a branch, optionally from another branch/tag/commit. */
async createBranch(owner, repo, { newBranch, fromBranch }) {
const payload = { new_branch_name: newBranch };
+19 -3
View File
@@ -67,6 +67,20 @@ export function branchMatches(refName, checkBranches) {
return list.some((b) => b === short || b === refName);
}
/**
* Whether a pull request should be reviewed.
*
* The check list names the *target* branches worth protecting, so a PR counts
* when it merges INTO a checked branch. That keeps "review everything that
* lands on prd/test" working even though feature branches are never listed.
* As a fallback the head branch is also matched, so explicitly listing a
* long-lived branch still reviews pushes and PRs originating from it.
*/
export function pullRequestMatches(headRef, baseRef, checkBranches) {
if (branchMatches(baseRef, checkBranches)) return true;
return branchMatches(headRef, checkBranches);
}
function badge(comment) {
const parts = [comment.category, comment.severity].filter(Boolean);
return parts.length ? `[${parts.join(" · ")}] ` : "";
@@ -188,9 +202,11 @@ async function resolveRange(runner, { repo, job, workspace, token }) {
if (job.from_sha) {
fromSha = await runner.revParse(workspace, job.from_sha);
}
// The review base is the managed branch: every checked branch is compared
// against what it would merge into, not against its own previous commit.
const baseBranch = job.managed_branch || job.base_ref;
// The review base is whatever this change would merge into: for a pull
// request that is the PR's own target branch, and only a bare push falls
// back to the managed branch. Preferring the managed branch here would
// compare a PR against an unrelated branch.
const baseBranch = job.base_ref || job.managed_branch;
if (!fromSha && baseBranch) {
const baseSha = await runner.revParse(workspace, `refs/remotes/origin/${baseBranch}`);
if (baseSha) fromSha = await runner.mergeBase(workspace, baseSha, toSha) ?? baseSha;