Apache Airflow PR 自动分诊Triage评论模板定制指南apache-magpie pr-management-triage 项目覆盖实践【免费下载链接】airflowApache Airflow - A platform to programmatically author, schedule, and monitor workflows项目地址: https://gitcode.com/GitHub_Trending/ai/airflowApache Airflow 仓库通过.apache-magpie-overrides/目录为 apache-magpie 框架的pr-management-triageskill 提供了一套项目级per-project评论模板定制方案。本文以 .apache-magpie-overrides/pr-management-triage-comment-templates.md 为骨架完整解析 Airflow 如何覆盖框架默认的 AI 辅助分诊评论包括项目专属 URL 占位符、质量标记字符串、AI 署名页脚、违规条目violations bullet的格式化规则以及request-author-confirmation这个唯一偏离框架默认的模板正文。读完本文你将掌握如何为任意 GitHub 项目尤其是 Apache 系仓库接入 magpie 分诊 skill 并定制一套可落地、低噪音、可被机器精确识别的 triage 评论体系。一、背景overrides 机制与本文档的定位Airflow 仓库的维护自动化建立在 apache-magpie 框架之上。框架自带一组 Claude skill如pr-management-triage而各采用方adopter仓库通过.apache-magpie-overrides/目录存放代理可读的覆盖指令按需覆盖框架 skill 的特定步骤或行为。正如 .apache-magpie-overrides/README.md 所述每个覆盖文件以它修改的框架 skill 命名如pr-management-triage系列文件对应同名 skill框架 skill 在运行时会先读取该目录再执行默认行为硬性规则不得修改已安装的插件本地改动一律放在 overrides 目录框架级改动通过 PR 提交到 apache/magpie 上游。.apache-magpie-overrides/pr-management-triage-comment-templates.md正是这套机制中pr-management-triageskill 的per-project comment-body library项目级评论正文库。它向框架提供三类 Airflow 专属取值渲染框架默认模板所需的项目专属 URLproject-specific URLsAI 署名页脚AI-attribution footer的措辞违规条目的 bullet 格式外加一个刻意偏离框架默认的模板正文——request-author-confirmation。其余所有模板均使用框架自带的默认正文仅注入本项目 URL 与措辞。说明框架侧的SKILL.md、comment-templates.md等属于 apache/magpie 框架安装内容Airflow 仓库内不保存其副本本文所引用的全部链接均以仓库根目录为起点指向 Airflow 仓库内确认存在的文件。二、项目专属 URL 占位符Project-specific URLs框架的默认模板正文中嵌有占位符本文档以表格形式为每个占位符提供 Airflow 项目的实际取值。这是整个评论库的地基——任何模板正文渲染时都会用下表替换占位符占位符项目取值含义quality_criteria_urlcontributing-docs/05_pull_requests.rst —— PR 质量标准章节two_stage_triage_rationale_urlcontributing-docs/25_maintainer_pr_triage.md —— 两级分诊中第一遍为何自动化的论证project_display_nameApache Airflowmerge_conflicts_rebase_urlcontributing-docs/10_working_with_git.rst —— 冲突解决与 rebase 指南static_checks_urlcontributing-docs/08_static_code_checks.rst —— 静态检查pre-commit / prek / ruff / mypytesting_urlcontributing-docs/09_testing.rst —— 测试指南docs_building_urlcontributing-docs/11_documentation_building.rst —— 文档构建helm_tests_urlcontributing-docs/testing/helm_unit_tests.rst —— Helm 单元测试k8s_tests_urlcontributing-docs/testing/k8s_tests.rst —— Kubernetes 测试provider_testing_urlcontributing-docs/12_provider_distributions.rst —— Provider 发行与测试project_communication_channelAirflow Slackproject_communication_urlhttps://s.apache-airflow-slack.io这些 URL 指向的文档均真实存在于本仓库的contributing-docs/目录下构成了分诊评论引导贡献者去解决问题的完整知识底座质量不达标 → 指向质量标准CI 失败 → 指向静态检查/测试/文档构建等专项指南冲突 → 指向 rebase 指南需要人工沟通 → 指向 Slack 频道。三、质量标记字符串机器如何识别已分诊的 PR框架使用一个字面量字符串来检测已被分诊triaged的 PR——它会在 PR 正文与评论中搜索该字符串。这是跨 skill 协作的关键契约概念取值Triage 标记的可见链接文本Pull Request quality criteria使用上有两条硬性要求不得改写Do not paraphraseskill 发布的每条分诊评论中必须原样出现该字符串跨 skill 共享pr-management-statsskill 使用同一个 marker 做该 PR 是否已分诊的判定。也就是说这个 marker 是分诊状态在文本层的唯一事实来源。如果某个模板把链接文本改成 PR quality standards 之类的措辞统计与去重逻辑会立即失配导致 PR 被重复分诊或统计失真。在 .apache-magpie-overrides/pr-management-config.md 中可以看到配套的标签体系如ready for maintainer review、closed because of multiple quality violationsmarker 与标签共同构成可机读的分诊状态机。四、AI 署名页脚AI-attribution footer每条面向贡献者的评论末尾都会追加一个逐字verbatim页脚块向贡献者透明说明评论的 AI 辅助来源。Airflow 的版本为--- _Note: This comment was drafted by an AI-assisted triage tool and may contain mistakes. Once you have addressed the points above, an Apache Airflow maintainer — a real person — will take the next look at your PR. We use this [two-stage triage process](https://github.com/apache/airflow/blob/main/contributing-docs/25_maintainer_pr_triage.md#why-the-first-pass-is-automated) so that our maintainers limited time is spent where it matters most: the conversation with you._定制原则可改措辞不可改结构。结构上必须保留两部分——斜体元信息块meta-block与指向两级分诊论证two-stage triage rationale的链接。这种设计把AI 可能犯错的免责、责任归属真人 maintainer 接管、流程透明度为何先机器后人工一次性讲清楚是大型开源项目规模化使用 AI 分诊时重要的信任机制。五、违规条目Violationsbullet 格式模板正文中的violations占位符会展开为 bullet 列表——每个 bullet 对应一类失败的检查或其他违规。Airflow 采用bare-category裸类别形式- :x: **category**. See docs.规则细节严重级别映射error用:x:warning用:warning:category与doc_link通过 .apache-magpie-overrides/pr-management-triage-ci-check-map.md 查表获得——每个类别一条 bullet无论有多少个具体检查名命中了该类别。5.1 不得列出单个失败的 Job 名称对框架默认的覆盖这是本文档中一个显式的框架覆盖分诊评论不得在类别下方枚举失败的检查名。例如以下写法被明确禁止:x: **Kubernetes tests** — Failing: Kubernetes tests / K8S System:LocalExecutor-3.10-v1.30.13-false, Kubernetes tests / K8S System:KubernetesExecutor-3.10-..., (1 more). See docs.同样被要求丢弃的还有框架默认渲染可能附加的逐类别补救片段如 Runprek run …locally and fix anything that flags. 之类。规则是bullet 只负责指向类别和文档 URL仅此而已。理由是GitHub 的Checks 标签页已经展示了失败 job 名称与重跑入口在分诊评论里重复它们只会增加噪音noise而不增加信息量signal评论过长会超出贡献者实际会读的长度阈值多个不同类别的违规 → 同一列表中的多条 bullet同一类别下的多个失败检查 → 仍然只有一条 bullet。从配套的 CI 检查映射表.apache-magpie-overrides/pr-management-triage-ci-check-map.md可以看出类别聚合的实际效果像mypy-airflow-core、mypy-...这类具体检查名都会被归并为mypy (type checking)一条并统一指向 contributing-docs/08_static_code_checks.rst。该表还规定了匹配语义大小写不敏感的子串匹配、顺序优先first-found——更具体的模式如mypy-必须列在更宽泛的模式之前此外还有两个回退规则mergeable CONFLICTING时单独输出 Merge conflicts 类别指向 contributing-docs/10_working_with_git.rst以及checks_state FAILURE但无法提取失败检查名时的通用 Failing CI checks 条目指向 catch-all 行同款文档。5.2 带内联 payload 的非 CI 违规少数违规自带一段在 bullet 内确实有用的短 payload未解决线程数、作者被标记的 PR 数、落后分支数等。对这些情况允许在类别后以内联方式追加 payload- :x: **category**: short payload. See docs.文档明确允许的两个示例- :x: **Unresolved review comments**: 3 thread(s). See docs.- :x: **Multiple flagged PRs**: flagged_count of your PRs are currently flagged for quality issues. Please focus on those before opening new ones.该条已逐字存在于下文close模板正文中原样保留边界约束很清晰payload必须是一个短子句绝不能是 job 名列表。如果发现自己在 payload 里列了三项以上内容就应回到 5.1 的规则——删掉它们让文档链接去完成解释工作。六、模板正文Template bodiesrequest-author-confirmation框架的默认comment-templates.md为每个分诊模板提供默认正文并通过项目专属 URL 表 AI 署名页脚渲染。本小节只收录 Airflow偏离框架默认的模板变体未列出的模板一律使用框架默认注入本项目 URL 与措辞后渲染。Airflow 唯一偏离默认的模板是request-author-confirmation请求作者确认。它用于这样的场景PR 上仍有若干未解决 review 线程但作者对每条线程都有回应提交了 review 后 commit 和/或线程内回复因此需要作者明确确认是否认为反馈已全部处理完毕、PR 是否已就绪。该模板正文必须逐字包含标记字符串ready for maintainer review confirmation——框架的viewer_confirmation_request_present前置条件classify-and-act 决策表中的检查项正是靠搜索这段精确文本来判断是否已发出过确认请求。与第三节的 marker 同理不要改写这个字符串。完整正文如下author — There are N unresolved review thread(s) on this PR, and you have engaged with each one (post-review commits and/or in-thread replies). Could you confirm whether you believe the feedback is fully addressed and the PR is ready for maintainer review confirmation? If yes, reply here (a short yes / ready is fine) and an Apache Airflow maintainer will pick the PR up from the review queue on the next sweep. If you are still working on a thread, please reply with what is outstanding so the threads stay unresolved on purpose. ai_attribution_footer模板结构值得注意的三点前置信息完整明确给出未解决线程数N与作者已逐一参与的事实依据让确认请求有据可循给出两种路径肯定回复简短 yes / ready 即可maintainer 将在下一轮 review 队列中接管与否定/进行中回复说明尚有哪些未完成项使线程有意保持未解决状态以页脚收尾ai_attribution_footer占位符渲染为第四节中的 AI 署名页脚。该模板与 .apache-magpie-overrides/pr-management-config.md 中的ready_for_maintainer_review标签Airflow 中为ready for maintainer review协同作者确认后由mark-ready动作打上该标签供pr-management-code-reviewskill 作为默认选择器使用形成分诊 → 作者确认 → 打标 → 进入真人 review 队列的完整闭环。七、覆盖文件的协同工作方式单个评论模板文件无法独立工作Airflow 在.apache-magpie-overrides/下用一组文件共同约束分诊行为覆盖文件职责pr-management-triage-comment-templates.md评论正文库URL 占位符、marker、页脚、bullet 格式、request-author-confirmation变体本文主角pr-management-triage-ci-check-map.mdCI 检查名 → 类别 → 文档 URL 的映射表violations bullet 的查表来源pr-management-config.md标识符committers_team、area_label_prefix、项目标签、宽限期阈值、反馈投递方式triage_feedback_channel: pr-body——确定性违规反馈折叠进 PR 描述而非发评论以压低 maintainer 邮箱噪音README.mdoverrides 机制总述与硬性规则渲染一条完整的违规分诊评论时框架的调用链大致为CI 状态 → 依据ci-check-map.md将失败检查归类为类别并取文档链接 → 按本文档的 bullet 格式生成violations→ 注入模板正文 → 解析项目专属 URL 占位符 → 追加 AI 署名页脚 → 按pr-management-config.md决定投递到 PR 正文还是评论。八、新项目采纳指引文档末尾给出了清晰的采纳路径任何希望接入 magpie 分诊的项目都可以照做将本文件复制为自有仓库的project-config/pr-management-triage-comment-templates.md用本项目的等价内容替换每一个Airflow 专属 URL 与措辞第二节表格逐行替换同步替换或新建pr-management-triage-ci-check-map.mdCI 检查映射与pr-management-config.md标签、阈值、反馈通道并保证 marker 字符串在所有评论中逐字一致除非确有理由否则保持框架默认模板仅在需要偏离默认时如本文的request-author-confirmation添加覆盖正文同时确保新的request-author-confirmation变体仍包含ready for maintainer review confirmation字面量。这套设计的核心经验可以总结为三点机器契约用字面量而非语义marker 字符串、确认请求字符串均不可改写、评论只承担导航职责类别 文档链接细节交给 Checks 标签页与文档、AI 透明度内置署名页脚 两级分诊论证链接。对贡献者流量大、维护者时间稀缺的 Apache 系项目这是一套经过 Airflow 实践校准的 PR 分诊评论范式。【免费下载链接】airflowApache Airflow - A platform to programmatically author, schedule, and monitor workflows项目地址: https://gitcode.com/GitHub_Trending/ai/airflow创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考