---
date: 2026-05-11
tags: [gitea, branch-protection, ci, pr-merge]
---

# Gitea `enable_status_check` 可能被 relax-restore 流程卡在 false，required check 形同虚设

## 现象

`docs/ops/02-gitea-config.md` 列了 5 个 develop required check，2026-05-11 加 `ai-review / ai-review (pull_request)` 转正时 `GET /branch_protections/develop` 发现：

```
enable_status_check: False
status_check_contexts: [5 个 quality-gates context]
```

即 contexts 已配置但 **开关是 off**。意味着这些检查长期"挂着名字、不阻断合并"，跟文档承诺的"必需状态检查"不一致。

## 根因（推断）

`scripts/ops/gitea-pr-merge.py` 默认走"relax 自审批字段 → merge → restore"模式。`--bypass-ci` 时会临时把 `enable_status_check` 设 false 让 merge 通过，merge 完再 restore。**任何一次 restore 失败 / 脚本中途被杀**，这个字段就卡在 false 直到下次手工修。

API 不会报错也不会告警，contexts 列表照常更新（PATCH `status_check_contexts` 成功 200），但开关是 false 时新加的 context 不会生效。

## 解决

```python
PATCH /repos/.../branch_protections/develop
{"enable_status_check": true}
```

立即生效，新旧 6 个 context 全部硬阻断。

## 排查方法（复用）

```bash
export GITEA_TOKEN="$GITEA_API_TOKEN"
curl -fsS -H "Authorization: token $GITEA_TOKEN" \
  http://43.130.59.228/api/v1/repos/FFAIWorkspace/workspace/branch_protections/develop \
  | jq '{enable_status_check, status_check_contexts}'
```

- 加 required check **必须同时确认** `enable_status_check: true`，否则只是登记不阻断
- staging / production 保护规则同理需要查
- 怀疑 relax-restore 流程出过事时，例行检查这个字段

## 关联

- `scripts/ops/gitea-pr-merge.py` 的 relax-restore 段
- CLAUDE.md「PR 自审批合并」段（提到默认保留 `enable_status_check`，但 `--bypass-ci` 会动它）
- 工单 #171 转正 ai-review 时发现