【免费下载链接】anti-slopA GitHub action that detects and automatically closes low-quality and AI slop PRs.项目地址https://gitcode.com/gh_mirrors/an/anti-slop点击查看免费下载anti-slop 是一个自动检测并关闭低质量与 AI slop PR 的 GitHub Action。本文从源码层面拆解它的 inherited 数据机制讲清楚它如何用一次 API 比较调用消灭 PR 指向非默认分支如next时产生的误报让检查只评价作者真正写出的代码。 一、问题背景为什么非默认分支 PR 会背锅多数仓库的 PR 直接指向默认分支main但不少团队采用发布流日常开发先进next分支再合回main。贡献者的 PR 常常指向next。当next落后于main时问题出现了main默认分支: A ── B ── C ── D │ nextPR目标分支: A ── B ── C │ featurePR源分支: A ── B ── C ── D ── E ↑ ↑ 继承而来 E作者真正的提交贡献者通常基于main拉分支feature 分支天然包含提交DPR 指向next时GitHub API 返回的 commit 列表和文件列表里会带出D以及它改动的文件这些内容不是本次 PR 作者写的但 commit 检查、file 检查会照单全收 → 误报误报累计达到max-failures默认 4时一个无辜 PR 就会被自动关闭。官方 CHANGELOG.md 用两个版本逐步修掉了这个问题v0.2.0将继承的默认分支提交排除出 commit 检查v0.2.1将继承文件排除出 file 检查并把检测逻辑抽取为共享模块️ 二、inherited 数据是什么一句话定义inherited 数据 仓库默认分支上已有、但 PR 目标分支尚未合入的那批 commit 和文件。数据结构非常简单定义在 src/types/inherited-data.tsexport interface InheritedData { shas: Setstring; // 继承的 commit sha files: Setstring; // 继承的文件路径 }两个Set各自提供 O(1) 的成员查找。下面看它们怎么产生。⚙️ 三、getInheritedData 源码拆解一次调用拿到全部核心实现在 src/inherited.ts总共 30 行左右关键有 4 步。第 1 步默认分支短路if (context.baseBranch context.defaultBranch) return { shas: new Set(), files: new Set() };见 src/inherited.ts。PR 直接指向main时继承数据必然为空直接返回空集合一次 API 都不发。这是最常见的场景这一行省掉了绝大多数请求。baseBranch与defaultBranch来自 PR 事件 payload提取逻辑在 src/context.ts。第 2 步一次 compare 拿到全部const { data } await client.rest.repos.compareCommitsWithBasehead({ owner: context.owner, repo: context.repo, basehead: ${context.baseBranch}...${context.defaultBranch}, });见 src/inherited.ts。注意三点语法next...main表示在main上但不在next上的 commit方向恰好就是继承集合反过来比就不对了。第 3 步构建两个 Setconst shas new Set(data.commits.map((commit) commit.sha)); const files new Set((data.files ?? []).map((file) file.filename));见 src/inherited.ts。第 4 步输出审计日志对每个继承的 commit 和文件各打一行core.info最后汇总Found X inherited commit(s) and Y inherited file(s)src/inherited.ts。维护者在 workflow 日志里一眼就能看到哪些内容被排除了。 四、inherited 数据的两个消费点4.1 commit 检查按 sha 过滤src/checks/commit-checks.ts 在拉取 PR 全部 commit 后立即过滤const commits allCommits.filter((commit) !inheritedShas.has(commit.sha));后续的 commit 消息长度、Conventional Commits、commit 作者匹配、block 作者四项检查全部跑在这份过滤后的列表上——继承 commit 永远不会被检查。4.2 file 检查按文件名过滤src/checks/file-checks.ts 同样的思路const files changedFiles .filter((file) !inheritedFiles.has(file.filename))文件扩展名、允许路径、block 路径、末尾换行、新增注释数这五项 file 检查都被这一行豁免了继承文件。4.3 单点采集、双点消费src/main.ts 中的调用顺序是先跑 branch / size / title 检查不需要 GitHub API再调用一次getInheritedData得到{ shas, files }shas传给 commit 检查files传给 file 检查。全程只发一次compare API 请求供两组检查共享——这正是 v0.2.1 重构要达到的效果。 五、inherited 数据机制的 3 个设计亮点设计点效果默认分支短路判断最常见场景指向main零 API 调用一次 compare 供两组检查复用请求更少、整个 action 更快官方宣传 15 秒内跑完只过滤内容类检查体积检查仍统计相对目标分支的实际增量与 GitHub 页面展示一致第三点值得展开max-changed-files/max-changed-lines并没有用 inherited 数据过滤统计直接来自 PR payload见 src/checks/size-checks.ts。这是有意为之——继承而来的改动会随这个 PR 一起落到目标分支计入体积是合理的真正造成误报的是把作者没写的代码算到作者头上。 六、误报修复时间线版本变化v0.2.0commit 检查排除继承 commit修复作者匹配、消息长度等检查的误报v0.2.1file 检查同样排除继承文件检测逻辑从 commit 检查中抽取为独立的 src/inherited.ts两组检查共享一次比较调用这条演进路径也展示了这类 bug 的通用修法先在误报最痛的检查点堵漏再重构为共享模块。 七、小结是什么inherited 数据 默认分支上已有、PR 目标分支尚未合入的 commit 与文件怎么来一次compareCommitsWithBaseheadbase...default外加默认分支短路判断怎么用shas过滤 commit 检查、files过滤 file 检查均为 O(1) 的Set查找解决什么anti-slop 只评价作者真正写的部分指向next等分支的 PR 不再被误关。想继续深入各检查实现都在 src/checks/ 目录下整体入口是 src/main.ts。赞分享【免费下载链接】anti-slopA GitHub action that detects and automatically closes low-quality and AI slop PRs.项目地址https://gitcode.com/gh_mirrors/an/anti-slop点击查看免费下载相关推荐Renovate 如何用 baseBranchPatterns 让更新 PR 指向非默认分支Renovate 如何用 baseBranchPatterns 让更新 PR 指向非默认分支 如果你的仓库默认分支是 main 但希望 Renovate 的依开发工具DevOps后端StackPrism 技术栈检测如何消灭误报规则预编译与 Hint 索引的完整源码剖析StackPrism 技术栈检测如何消灭误报规则预编译与 Hint 索引的完整源码剖析 StackPrism 是一款开源的网页技术栈检测浏览器扩展brows深度解析 PostgreSQL 默认 Schema 机制search_path 如何决定建表位置深度解析 PostgreSQL 默认 Schema 机制search_path 如何决定建表位置 PostgreSQL 中的 Schema模式是组织表、视文档教程知识管理上一篇OpenMemories-Tweak索尼相机隐藏功能深度解锁专业指南下一篇如何彻底解决Windows 11中PL2303驱动黄色感叹号问题完整技术指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
【免费下载链接】anti-slopA GitHub action that detects and automatically closes low-quality and AI slop PRs.项目地址https://gitcode.com/gh_mirrors/an/anti-slop点击查看免费下载anti-slop 是一个自动检测并关闭低质量与 AI slop PR 的 GitHub Action。本文从源码层面拆解它的 inherited 数据机制讲清楚它如何用一次 API 比较调用消灭 PR 指向非默认分支如next时产生的误报让检查只评价作者真正写出的代码。 一、问题背景为什么非默认分支 PR 会背锅多数仓库的 PR 直接指向默认分支main但不少团队采用发布流日常开发先进next分支再合回main。贡献者的 PR 常常指向next。当next落后于main时问题出现了main默认分支: A ── B ── C ── D │ nextPR目标分支: A ── B ── C │ featurePR源分支: A ── B ── C ── D ── E ↑ ↑ 继承而来 E作者真正的提交贡献者通常基于main拉分支feature 分支天然包含提交DPR 指向next时GitHub API 返回的 commit 列表和文件列表里会带出D以及它改动的文件这些内容不是本次 PR 作者写的但 commit 检查、file 检查会照单全收 → 误报误报累计达到max-failures默认 4时一个无辜 PR 就会被自动关闭。官方 CHANGELOG.md 用两个版本逐步修掉了这个问题v0.2.0将继承的默认分支提交排除出 commit 检查v0.2.1将继承文件排除出 file 检查并把检测逻辑抽取为共享模块️ 二、inherited 数据是什么一句话定义inherited 数据 仓库默认分支上已有、但 PR 目标分支尚未合入的那批 commit 和文件。数据结构非常简单定义在 src/types/inherited-data.tsexport interface InheritedData { shas: Setstring; // 继承的 commit sha files: Setstring; // 继承的文件路径 }两个Set各自提供 O(1) 的成员查找。下面看它们怎么产生。⚙️ 三、getInheritedData 源码拆解一次调用拿到全部核心实现在 src/inherited.ts总共 30 行左右关键有 4 步。第 1 步默认分支短路if (context.baseBranch context.defaultBranch) return { shas: new Set(), files: new Set() };见 src/inherited.ts。PR 直接指向main时继承数据必然为空直接返回空集合一次 API 都不发。这是最常见的场景这一行省掉了绝大多数请求。baseBranch与defaultBranch来自 PR 事件 payload提取逻辑在 src/context.ts。第 2 步一次 compare 拿到全部const { data } await client.rest.repos.compareCommitsWithBasehead({ owner: context.owner, repo: context.repo, basehead: ${context.baseBranch}...${context.defaultBranch}, });见 src/inherited.ts。注意三点语法next...main表示在main上但不在next上的 commit方向恰好就是继承集合反过来比就不对了。第 3 步构建两个 Setconst shas new Set(data.commits.map((commit) commit.sha)); const files new Set((data.files ?? []).map((file) file.filename));见 src/inherited.ts。第 4 步输出审计日志对每个继承的 commit 和文件各打一行core.info最后汇总Found X inherited commit(s) and Y inherited file(s)src/inherited.ts。维护者在 workflow 日志里一眼就能看到哪些内容被排除了。 四、inherited 数据的两个消费点4.1 commit 检查按 sha 过滤src/checks/commit-checks.ts 在拉取 PR 全部 commit 后立即过滤const commits allCommits.filter((commit) !inheritedShas.has(commit.sha));后续的 commit 消息长度、Conventional Commits、commit 作者匹配、block 作者四项检查全部跑在这份过滤后的列表上——继承 commit 永远不会被检查。4.2 file 检查按文件名过滤src/checks/file-checks.ts 同样的思路const files changedFiles .filter((file) !inheritedFiles.has(file.filename))文件扩展名、允许路径、block 路径、末尾换行、新增注释数这五项 file 检查都被这一行豁免了继承文件。4.3 单点采集、双点消费src/main.ts 中的调用顺序是先跑 branch / size / title 检查不需要 GitHub API再调用一次getInheritedData得到{ shas, files }shas传给 commit 检查files传给 file 检查。全程只发一次compare API 请求供两组检查共享——这正是 v0.2.1 重构要达到的效果。 五、inherited 数据机制的 3 个设计亮点设计点效果默认分支短路判断最常见场景指向main零 API 调用一次 compare 供两组检查复用请求更少、整个 action 更快官方宣传 15 秒内跑完只过滤内容类检查体积检查仍统计相对目标分支的实际增量与 GitHub 页面展示一致第三点值得展开max-changed-files/max-changed-lines并没有用 inherited 数据过滤统计直接来自 PR payload见 src/checks/size-checks.ts。这是有意为之——继承而来的改动会随这个 PR 一起落到目标分支计入体积是合理的真正造成误报的是把作者没写的代码算到作者头上。 六、误报修复时间线版本变化v0.2.0commit 检查排除继承 commit修复作者匹配、消息长度等检查的误报v0.2.1file 检查同样排除继承文件检测逻辑从 commit 检查中抽取为独立的 src/inherited.ts两组检查共享一次比较调用这条演进路径也展示了这类 bug 的通用修法先在误报最痛的检查点堵漏再重构为共享模块。 七、小结是什么inherited 数据 默认分支上已有、PR 目标分支尚未合入的 commit 与文件怎么来一次compareCommitsWithBaseheadbase...default外加默认分支短路判断怎么用shas过滤 commit 检查、files过滤 file 检查均为 O(1) 的Set查找解决什么anti-slop 只评价作者真正写的部分指向next等分支的 PR 不再被误关。想继续深入各检查实现都在 src/checks/ 目录下整体入口是 src/main.ts。赞分享【免费下载链接】anti-slopA GitHub action that detects and automatically closes low-quality and AI slop PRs.项目地址https://gitcode.com/gh_mirrors/an/anti-slop点击查看免费下载相关推荐Renovate 如何用 baseBranchPatterns 让更新 PR 指向非默认分支Renovate 如何用 baseBranchPatterns 让更新 PR 指向非默认分支 如果你的仓库默认分支是 main 但希望 Renovate 的依开发工具DevOps后端StackPrism 技术栈检测如何消灭误报规则预编译与 Hint 索引的完整源码剖析StackPrism 技术栈检测如何消灭误报规则预编译与 Hint 索引的完整源码剖析 StackPrism 是一款开源的网页技术栈检测浏览器扩展brows深度解析 PostgreSQL 默认 Schema 机制search_path 如何决定建表位置深度解析 PostgreSQL 默认 Schema 机制search_path 如何决定建表位置 PostgreSQL 中的 Schema模式是组织表、视文档教程知识管理上一篇OpenMemories-Tweak索尼相机隐藏功能深度解锁专业指南下一篇如何彻底解决Windows 11中PL2303驱动黄色感叹号问题完整技术指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
