# action-daily

**Repository Path**: farfarfun/action-daily

## Basic Information

- **Project Name**: action-daily
- **Description**: No description available
- **Primary Language**: Unknown
- **License**: MIT
- **Default Branch**: main
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2026-09-19
- **Last Updated**: 2026-10-23

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# action-daily

farfarfun 组织的定时任务集合：把公开仓库镜像同步到 Gitee，并对照组织开发规范
（[farfarfun/todo-list](https://github.com/farfarfun/todo-list) 的 `SPEC.md`）
滚动做合规审计、自动提交修复。

本仓库只有 GitHub Actions workflow 和配套的 Python 脚本，不是可安装的包，没有 PyPI 发布。

## Mirror to Gitee

`Mirror to Gitee` 每 2 小时增量运行一次，每天额外跑一次全量（Asia/Shanghai 凌晨），
也可手动触发（`workflow_dispatch`，可强制全量）。它会把 `farfarfun` 组织下所有**公开**
仓库（含 fork）镜像同步到 Gitee 的 `farfarfun` 组织，不会同步私有仓库。

镜像本身由 [`farfarfun-action/mirror-repo`](https://github.com/farfarfun-action/mirror-repo)
完成——我们自己写的 Action，底层调用 [`farfarfun/funmirror`](https://github.com/farfarfun/funmirror)
这个两阶段（detect 高并发探测 commit sha → sync 低并发 clone+push）镜像流水线，
详细架构图见该仓库的 README。增量档只查 GitHub 一侧的 commit sha，命中
`.mirror-state/gitee.json` 里记录的状态就跳过；全量档同时查询 GitHub 和 Gitee 两侧，
忽略状态文件，自愈任何漂移（例如有人手动改动了 Gitee 上的仓库）。状态文件每次运行后
都会提交回本仓库，以便在无状态的 runner 之间延续。

需要在本仓库的 Actions secrets 中配置：

- `GITEE_TOKEN`：Gitee 私人令牌，需要有 `projects` 权限，用于在 `farfarfun` 组织下创建/更新仓库。
- `GITEE_RSA_PRIVATE_KEY`：用于推送代码的 SSH 私钥，对应公钥需添加到该 Gitee 账号的 SSH 公钥中。
- `ACTION_GITHUB_TOKEN`：org 级 GitHub token，用于列举组织仓库。

配置好后，Gitee 侧需已存在 `farfarfun` 组织（个人无法在他人组织下自动建仓）。

## Codex 规范审计

两条 workflow 配合，一条找问题、一条修问题，issue 统一建在 `farfarfun/todo-list`：

| workflow | 定时 | 做什么 |
| --- | --- | --- |
| `codex-find-issues.yml` | 每 5 小时一批 | 按游标滚动选一批仓库，用 Codex CLI 对照 `SPEC.md` 做只读审计，命中就建 issue（label `codex-audit`） |
| `codex-fix-issues.yml` | 每小时 5 条 | 取最旧的 open `codex-audit` issue，clone 目标仓库交给 Codex CLI 修复，提交到 `automation/codex-fix-*` 分支并开 PR，issue 标为 `fix-proposed` |
| `merge-automation-prs.yml` | 每 15 分钟 | 扫描全组织仓库，把检查通过的 `automation/*` 分支 PR 合并到默认分支；合并的是 `automation/codex-fix-*` 分支时，同步把对应 issue 标为 `fix-applied` 并关闭 |

脚本分工：

- `scripts/codex_audit_cursor.py`：算本轮批次，游标存 `scripts/codex_audit_cursor.json`（跨运行保留，会提交回本仓库）
- `scripts/run_codex_audit.py`：逐仓库 clone + 跑 Codex，发现写 `scripts/codex_audit_findings.json`
- `scripts/file_codex_audit_issues.py`：按仓库聚合、过滤 low 置信度、去重后建 issue
- `scripts/codex_audit_schema.json`：Codex 输出的 JSON schema

`codex-fix-issues.yml` 的自动化 token 没有 workflow scope，如果 Codex 的改动涉及
`.github/workflows/`，这部分会被丢弃、PR 只带其余改动；若整条改动都在 workflow 下，
则不建 PR，issue 标为 `manual-required` 转人工处理。若 Codex 复核后判断是误报、没有
产生任何改动，issue 标为 `audit-dismissed` 并关闭标签转换（但 issue 本身保持当前
open/closed 状态不变）。

需要的 Actions secrets：`ACTION_GITHUB_TOKEN`（跨仓库读写 issue 与 clone 私有仓库）、
`OPENAI_API_KEY`、`OPENAI_BASE_URL`（走自定义/代理的 OpenAI 兼容端点）。

### 本地运行

脚本只用 Python 标准库（`>=3.10`，与组织统一下限一致，未用到 3.11/3.12 专属语法），
不需要安装 Python 依赖。本地运行前安装
[`gh`](https://cli.github.com/) 和 [`codex`](https://github.com/openai/codex) CLI；以下命令适用于
macOS（Homebrew）或 Debian/Ubuntu。其他平台请使用各工具的官方安装说明：

```bash
# macOS
brew install gh node

# Debian/Ubuntu（二选一，不要与上面的 macOS 命令同时运行）
sudo apt update && sudo apt install -y gh nodejs npm

npm install -g @openai/codex
gh auth login
```

`gh auth login` 的 token 必须能读取组织内待审计仓库，并能在 `farfarfun/todo-list`
创建 issue。`codex` 可执行 `codex login` 完成登录；使用 API 或自定义兼容端点时，按下面的
`OPENAI_API_KEY` 和可选 `OPENAI_BASE_URL` 环境变量配置即可。

GitHub Actions 会自行安装 Python、Node.js 和 Codex CLI，并从 Actions secrets 读取凭据；
下面的命令仅适用于本地运行：

```bash
# 准备：SPEC.md / mapping.json 来自 todo-list，克隆一份供脚本读取
git clone --depth 1 https://github.com/farfarfun/todo-list.git todo-list-ref
export TODO_LIST_DIR="$PWD/todo-list-ref"

# 1) 选本轮批次（会推进 scripts/codex_audit_cursor.json 里的游标）
python3 scripts/codex_audit_cursor.py

# 只想扫指定仓库时跳过上一步，手写批次文件即可
echo '["funfile", "funget"]' > scripts/codex_audit_batch.json

# 2) 跑审计（结果写 scripts/codex_audit_findings.json）
export ORG_PAT="<github token>"           # clone 目标仓库用，含私有仓库
export OPENAI_API_KEY="<key>"
export OPENAI_BASE_URL="<endpoint>"       # 可选，留空则走官方 OpenAI 端点
export PYTHON_STANDARDS_PATH="<lang-spec-hub>/skills/python-development-standards/SKILL.md"
python3 scripts/run_codex_audit.py

# 3) 建 issue（默认直接写到 farfarfun/todo-list，先看 findings 再执行）
python3 scripts/file_codex_audit_issues.py
```

`ORG_PAT` 只通过环境变量传入，clone 时用 `http.extraheader` 认证，不会写进命令行参数
或目标仓库的 `.git/config`。

Gitee 镜像没有本地入口，逻辑都在 `farfarfun-action/mirror-repo` 里，本地复现请直接用
`farfarfun/funmirror`。

## Merge all PRs

`merge-all-prs.yml` 只手动触发（`workflow_dispatch`），把 `farfarfun` 组织下**所有**仓库的
open PR 批量合并——不限 `automation/*` 分支，这是它和 `merge-automation-prs.yml` 的区别。
因为影响面大，默认跑 dry run：只在 job summary 里列出会合并/跳过哪些 PR 以及原因，确认后
再把 `dry_run` 关掉实跑。

可选输入：

| 输入 | 默认 | 说明 |
| --- | --- | --- |
| `repos` | 空（全组织，跳过已归档仓库） | 仓库过滤，逗号/空格分隔，`funfile` 或 `farfarfun/funfile` 都行 |
| `dry_run` | `true` | 只列出计划，不实际合并 |
| `merge_method` | `squash` | `squash` / `merge` / `rebase` |
| `require_checks` | `true` | 要求该 commit 上的 check-runs 无 pending、无失败 |
| `include_forks` | `false` | 默认只处理 head 仓库属于 `farfarfun` 的 PR |
| `update_branch` | `true` | `mergeable_state` 为 `behind` 时先更新分支，本轮不合并 |

无论怎么配置，以下 PR 一律跳过：draft、带 `do-not-merge` / `wip` / `blocked` / `hold`
label、以及 `mergeable_state` 不是 `clean` 的（关掉 `require_checks` 时额外允许
`unstable`）。合并 `automation/codex-fix-*` 分支时，同样会把 `farfarfun/todo-list`
里对应的 issue 标为 `fix-applied` 并关闭。有任何 PR 操作失败时该 run 会以失败收尾。

用的 secret 和 Codex 审计一致：`ACTION_GITHUB_TOKEN`。

---

## 关于 farfarfun

[farfarfun](https://github.com/farfarfun) 是一个专注于实用工具库的开源组织，
涵盖云存储、数据处理、AI、多媒体与开发工具链等方向。

- 🏠 组织主页：<https://github.com/farfarfun>
- 📧 联系：farfarfun@qq.com

本项目基于 [MIT](LICENSE) 协议开源。