Anomalib 贡献者 PR 提交流程与质量门禁全指南标题规范、分支命名与合并就绪检查【免费下载链接】anomalibAn anomaly detection library comprising state-of-the-art algorithms and features such as experiment management, hyper-parameter optimization, and edge inference.项目地址: https://gitcode.com/GitHub_Trending/an/anomalib导读本文基于 Anomalib 仓库内置的pr-workflow审查技能.agents/skills/pr-workflow/SKILL.md系统梳理该项目对贡献者的 Pull RequestPR提交要求从 Conventional Commits 标题格式、type/scope/description分支命名到本地质量门禁、CI 校验与安全扫描的完整链路。读完本文你将掌握 Anomalib 的合并就绪merge readiness判定标准知道如何写一个合规的 PR 标题、起一个规范的分支名、跑通全部质量检查并理解维护者在审查 PR 时重点关注哪些文件与风险。一、pr-workflow 技能的定位与适用场景在 Anomalib 仓库的.agents目录下维护者为 AI 审查 Agent 提供了一套名为pr-workflow的技能定义。它并不是一篇泛泛的团队规范而是一份可直接执行的操作指令用于在以下场景中辅助判断变更是否达到可贡献、可合并的标准合并就绪评估merge readiness判断一个 PR 是否具备合并条件贡献者工作流审查contributor workflow检查 fork、分支、提交与 PR 提交流程是否合规CI 预期核对CI expectations确认变更与仓库配置的持续集成门禁一致PR 标题与分支命名校验逐项检查标题的 Conventional Commit 格式与分支命名格式。技能文件通过 YAML frontmatter 声明自身能力边界name: pr-workflow、description: Reviews anomalib contributor workflow, PR title, branch naming, and quality gate expectations正文则给出具体的触发条件、质量门禁、审查锚点与检查清单。这意味着凡是标题不合规、分支命名错误、缺少测试/文档/变更日志、或工作流与安全敏感文件未按仓库标准审查的 PR都应被要求修改Request changes。二、PR 标题必须遵循 Conventional Commits2.1 为什么标题如此重要Anomalib 采用squash merge压缩合并策略PR 合入后标题会直接成为主分支上的最终提交信息并用于 Commitizen 生成CHANGELOG.md。因此技能明确要求开发过程中的单个 commit 可以是任意格式如wip、fix typo但 PR 标题必须以 Conventional Commit 格式书写。这一约束同时写入 CONTRIBUTING.md 与仓库文档 docs/source/markdown/guides/developer/contributing.md。2.2 标题的标准结构PR 标题由header必填、可选的body与footer组成type(scope): description [optional body] [optional footer]其中 type 与 scope 均大小写敏感type 必须为小写。2.3 允许的 type 与 scopeAnomalib 允许的type共 10 种type含义feat新功能fix缺陷修复docs文档变更style代码风格调整refactor代码重构perf性能优化test新增或修改测试build构建系统变更ciCI 配置变更chore常规维护允许的scope共 13 种data、model、metric、utils、cli、docs、ci、engine、visualization、benchmarking、logger、openvino、notebooks。这一枚举并非口头约定而是硬编码在仓库的 Commitizen 配置中pyproject.toml 的[tool.commitizen]段声明了name cz_conventional_commits、types与scopes列表同时在[tool.commitizen.rules]中通过scope-enum [2, always, [...]]强制 scope 必须落在上述枚举内。也就是说本地 Commitizen 校验与 CI 中的 PR 标题校验共用同一份规则源。2.4 标题书写规则type 与 scope 大小写敏感type 必须小写description 使用现在时态present tensedescription 末尾不加句号description 不得使用 sentence-case、start-case、pascal-case 或 upper-casetype/scope 与描述之间保持严格的type(scope): description冒号加空格格式。合法示例feat(model): add transformer architecture for anomaly detection fix(data): handle corrupted image files during training docs: update installation instructions for Windows chore(ci): migrate from commit message validation to PR title validation2.5 可选 emoji 前缀标题开头可以非必须附加 emoji 以增强可读性技能与 CI 校验都会在验证前剥离 emoji feat(model): add transformer architecture for anomaly detection fix(data): handle corrupted image files during training docs: update installation instructions for Windows chore(ci): migrate from commit message validation to PR title validation推荐映射→feat、→fix、→docs、→style、→refactor、⚡→perf、→test、→build、→chore、→ci。注意 emoji 只是可选装饰不带 emoji 的标题同样有效。2.6 CI 侧的真实校验实现仓库通过可复用工作流 _reusable-pr-title-check.yaml 强制校验 PR 标题其执行逻辑可以印证上述规则安装commitizen4.13.9工作流第 82 行读取github.event.pull_request.title用 Python 正则剥离标题开头的 emoji第 97 行覆盖表情符号、杂项符号、旗帜等多段 Unicode 区间将清洗后的标题写入临时文件执行cz check --commit-msg-file $TEMP_TITLE_FILE第 110 行校验失败时输出详细错误提示格式示例、建议 emoji 等并退出码为 1。该工作流由 pr.yaml 在pull_request事件上调用仅对真实 PR 执行merge group 跳过并且只校验标题而非单个 commit 消息——这与 squash merge 策略完全对应。三、分支命名严格遵循type/scope/description3.1 命名格式分支名必须符合type/scope/description其中 type 与 scope 必须与提交消息中使用的枚举一致即上文的 10 种 type、13 种 scope。合法示例feat/model/add-transformerfix/data/load-image-bugdocs/readme/update-installationrefactor/utils/optimize-performance3.2 pre-commit 层强制分支命名并非只靠人肉自觉。.pre-commit-config.yaml 引入了commitizen-tools/commitizen仓库的commitizen-branch钩子配置在pre-push阶段执行注释明确写道Only enforce branch naming, not commit messages (since we validate PR titles instead)。也就是说推送分支时 pre-commit 就会拦截不合规的分支名从源头保证命名质量。3.3 开发过程与提交流程技能与 CONTRIBUTING.md 允许开发期间使用任意格式的提交例如git add files git commit -m wip: working on transformer model git commit -m fix typo git commit -m address review comments提交 PR 时只需保证标题合规。如需借助 Commitizen 工具可以这样本地校验# 校验单条消息是否符合 conventional 格式 echo feat(model): add transformer architecture | cz check --commit-msg-file - # 校验提交历史 cz check # 依据提交历史生成版本号并更新 CHANGELOG.md cz bump四、质量门禁本地检查与自动化验证4.1 提交前必须执行的两条命令技能明确规定贡献者在最终确定 PR 前需要运行prek run --all-files pytest tests/prek run --all-filespre-commit 的增强封装对所有文件执行仓库配置的全部钩子pytest tests/运行 tests/ 下的完整测试套件单元测试与集成测试其中集成测试在tests/integration/单元测试在tests/unit/。开发环境搭建方式见 CONTRIBUTING.md创建 Conda 环境后通过anomalib install --option dev或pip install -e .[dev]安装开发依赖再执行prek install安装钩子。4.2 pre-commit 钩子清单.pre-commit-config.yaml 完整定义了仓库的质量基线注意其exclude: ^application/即 Anomalib Studio 桌面应用使用独立的 CI 设置钩子版本作用trailing-whitespace/end-of-file-fixerpre-commit-hooks v5.0.0基础格式清理check-yaml/check-added-large-files/debug-statements/detect-private-key同上YAML 校验、大文件拦截、调试语句与私钥检测commitizen-branchcommitizen v4.8.3pre-push 阶段强制分支命名ruff/ruff-formatruff v0.12.0Python lint含--fix自动修复与格式化mypyv1.16.1静态类型检查tests与.semgrep/除外bandit1.8.5安全扫描按pyproject.toml配置运行severity ≥ medium、confidence ≥ high 才报告nbqa-ruffnbQA 1.9.1Jupyter notebook 的 ruff 检查prettierv4.0.0-alpha.8前端与部分文本格式化markdownlintv0.45.0Markdown 文档规范gitleaksv8.30.1密钥/凭据泄漏检测zizmorv1.9.0GitHub Actions 工作流安全审计--min-severity medium --min-confidence high同时 pyproject.toml 中配置了 ruff 与 mypy 的具体规则集审查反馈应始终以这些配置为准而不是审查者个人的口味偏好——这正是技能中Review feedback should align with the projects configured checks inpyproject.tomland.pre-commit-config.yaml的含义。4.3 CI 流水线的构成pr.yaml 是 PR 阶段的编排工作流除标题校验外还并行执行quality通过prek workspace mode同时覆盖库代码src/与application/执行代码风格、类型检查与全部 pre-commit 钩子security复用 _reusable-security-scan.yaml本次 PR 运行semgrep,bandit,zizmor三款工具scan-scope: changed只扫描变更文件severity-level: LOW、confidence-level: HIGH且fail-on-findings: true显式开启失败即拦截unit-tests / integration-tests通过check-paths判断是否涉及库代码路径src/**、tests/**、examples/**、tools/**、pyproject.toml、uv.lock、.pre-commit-config.yaml、tox.ini等单元测试跑在ubuntu-latest30 分钟超时集成测试跑在self-hosted60 分钟超时docker-build当变更涉及application/**或.github/**时构建并上传 Docker 镜像状态汇总 joblibrary-checks-status/docker-build-status聚合各子任务结果任一失败则整体报错阻止合并。工作流还通过concurrency配置了cancel-in-progress: true新提交推送后会自动取消旧运行避免排队浪费。五、安全敏感变更六工具协同审查5.1 安全工具矩阵SECURITY.md 明确了项目采用pre-commit、PR 检查、周期扫描三档安全防线技能要求审查者据此核查安全敏感变更工具类型Pre-commitPR 检查周期扫描CodeQL静态分析Python GitHub Actions✅✅Semgrep静态分析含 Trail of Bits 的 ML 专项规则✅✅BanditPython 静态分析✅✅✅ZizmorGitHub Actions 工作流审计✅✅✅Trivy依赖漏洞与配置错误检查✅Dependabot依赖安全更新✅注意Semgrep 因 不支持 Windows 未纳入 pre-commit因此依赖 CI 层覆盖。5.2 误报抑制规范仓库接受带理由的告警抑制注释见 CONTRIBUTING.md审查者在看到相关注释时应确认其合理性Bandit# nosec BXXX例如import subprocess # nosec B404 # this is actually fineZizmor# zizmor: ignore[rulename]例如uses: actions/checkoutv3 # zizmor: ignore[artipacked] this is actually fineSemgrep# nosemgrep: rule-id例如# nosemgrep: python.lang.security.audit.dangerous-system-call.dangerous-system-call。规则是必须同时说明为什么禁用该规则/为何接受该风险单纯贴注释而不解释不被接受。六、仓库级审查锚点Repo-grounded anchors技能强调审查必须以仓库政策为依据并给出六份锚定文档作为审查时的裁决基准CONTRIBUTING.md —— 贡献总纲含 PR 标题格式、分支命名、开发工作流与 Commitizen 用法docs/source/markdown/guides/developer/contributing.md —— 文档站的贡献指南内容与 CONTRIBUTING.md 同源docs/source/markdown/guides/developer/code_review_checklist.md —— 代码审查清单从代码质量、架构设计、功能正确性、安全、性能、测试、文档注释、兼容性八个维度给出 40 余条检查项.pre-commit-config.yaml —— 质量钩子配置决定prek run --all-files实际执行什么pyproject.toml —— ruff/mypy 规则、Commitizen type/scope 枚举、Bandit 配置等一切工具的规则源SECURITY.md —— 安全策略、漏洞报告渠道与安全工具矩阵。.github/pull_request_template.md 还提供了 PR 模板贡献者需勾选变更类型feature/bugfix/refactor/perf/style/tests/docs/build/CI/chore/security/breaking change并确认已更新文档、已编写测试、标题遵循 conventional commit 格式。七、审查者的期望与严格边界7.1 审查原则具体、可执行、有政策依据反馈应基于仓库策略提出精确的修复建议而非笼统的个人偏好先升级后批准缺少测试、缺少文档、缺少 changelog 条目或存在工作流/安全风险时不得放行高风险区域从严技能明确列出需要更严格审查的文件类别——CLI 入口点CLI entrypoints、CI 工作流workflows、部署相关deployment、推理器inferencers以及面向用户的公开 APIuser-facing public APIs。从仓库结构看这些高风险区分别对应 src/anomalib/cli/、.github/workflows/、src/anomalib/deploy/、src/anomalib/deploy/inferencers/ 等目录改动这些模块时审查者会逐条核对行为兼容性与文档同步。7.2 变更日志要求技能要求 PR 缺失 changelog 条目时发起修改请求。仓库采用 Commitizen 自动生成变更日志pyproject.toml 中update_changelog_on_bump true、changelog_file CHANGELOG.md、changelog_format ## $version ($date)因此合规的 PR 标题是 changelog 质量的前提重大变更还应主动向 CHANGELOG.md 补充摘要。八、审查提问与最终检查清单技能内置了三个标准审查提问可直接用于任何 PR 的快速评估Is the PR title valid for the eventual squash commit?—— 标题在压缩合并后能否直接作为正式提交信息Are branch naming, changelog, tests, and docs in good shape for merge?—— 分支名、变更日志、测试与文档是否都达到合并条件Do the requested changes line up with the projects existing CI and security gates?—— 变更是否与仓库现有 CI 与安全门禁一致最终逐项核对清单与技能一致PR 标题符合 Conventional Commits 格式type/scope 落在 pyproject.toml 枚举内description 为现在时、无句号分支命名符合type/scope/descriptionpre-push 阶段由 commitizen-branch 钩子强制已通过prek run --all-files与pytest tests/CI 的 pr-title-check、quality、security、unit-tests、integration-tests、docker-build 全部通过测试、文档、changelog 齐备且与变更匹配工作流与安全敏感文件CLI、workflows、deployment、inferencers、公开 API已按仓库标准从严审查安全工具Bandit、CodeQL、Semgrep、Zizmor、Trivy、Dependabot无未解决发现误报抑制注释均附带充分的理由说明。结语Anomalib 的 PR 工作流是一条本地 pre-commit → 推送分支校验 → CI 标题/质量/安全/测试 → 人工审查的完整链路而pr-workflow技能的价值在于把这条链路的判定标准显式化标题与分支命名由 pyproject.toml 的 Commitizen 配置统一定义质量基线由 .pre-commit-config.yaml 固化为可执行钩子安全底线由 SECURITY.md 与 pr.yaml 的扫描任务兜底最终由审查者依据 code_review_checklist.md 逐项把关。对照本文梳理的清单逐项自检你的下一个 PR 就能顺畅通过全部门禁安心等待合并。【免费下载链接】anomalibAn anomaly detection library comprising state-of-the-art algorithms and features such as experiment management, hyper-parameter optimization, and edge inference.项目地址: https://gitcode.com/GitHub_Trending/an/anomalib创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Anomalib 贡献者 PR 提交流程与质量门禁全指南：标题规范、分支命名与合并就绪检查
Anomalib 贡献者 PR 提交流程与质量门禁全指南标题规范、分支命名与合并就绪检查【免费下载链接】anomalibAn anomaly detection library comprising state-of-the-art algorithms and features such as experiment management, hyper-parameter optimization, and edge inference.项目地址: https://gitcode.com/GitHub_Trending/an/anomalib导读本文基于 Anomalib 仓库内置的pr-workflow审查技能.agents/skills/pr-workflow/SKILL.md系统梳理该项目对贡献者的 Pull RequestPR提交要求从 Conventional Commits 标题格式、type/scope/description分支命名到本地质量门禁、CI 校验与安全扫描的完整链路。读完本文你将掌握 Anomalib 的合并就绪merge readiness判定标准知道如何写一个合规的 PR 标题、起一个规范的分支名、跑通全部质量检查并理解维护者在审查 PR 时重点关注哪些文件与风险。一、pr-workflow 技能的定位与适用场景在 Anomalib 仓库的.agents目录下维护者为 AI 审查 Agent 提供了一套名为pr-workflow的技能定义。它并不是一篇泛泛的团队规范而是一份可直接执行的操作指令用于在以下场景中辅助判断变更是否达到可贡献、可合并的标准合并就绪评估merge readiness判断一个 PR 是否具备合并条件贡献者工作流审查contributor workflow检查 fork、分支、提交与 PR 提交流程是否合规CI 预期核对CI expectations确认变更与仓库配置的持续集成门禁一致PR 标题与分支命名校验逐项检查标题的 Conventional Commit 格式与分支命名格式。技能文件通过 YAML frontmatter 声明自身能力边界name: pr-workflow、description: Reviews anomalib contributor workflow, PR title, branch naming, and quality gate expectations正文则给出具体的触发条件、质量门禁、审查锚点与检查清单。这意味着凡是标题不合规、分支命名错误、缺少测试/文档/变更日志、或工作流与安全敏感文件未按仓库标准审查的 PR都应被要求修改Request changes。二、PR 标题必须遵循 Conventional Commits2.1 为什么标题如此重要Anomalib 采用squash merge压缩合并策略PR 合入后标题会直接成为主分支上的最终提交信息并用于 Commitizen 生成CHANGELOG.md。因此技能明确要求开发过程中的单个 commit 可以是任意格式如wip、fix typo但 PR 标题必须以 Conventional Commit 格式书写。这一约束同时写入 CONTRIBUTING.md 与仓库文档 docs/source/markdown/guides/developer/contributing.md。2.2 标题的标准结构PR 标题由header必填、可选的body与footer组成type(scope): description [optional body] [optional footer]其中 type 与 scope 均大小写敏感type 必须为小写。2.3 允许的 type 与 scopeAnomalib 允许的type共 10 种type含义feat新功能fix缺陷修复docs文档变更style代码风格调整refactor代码重构perf性能优化test新增或修改测试build构建系统变更ciCI 配置变更chore常规维护允许的scope共 13 种data、model、metric、utils、cli、docs、ci、engine、visualization、benchmarking、logger、openvino、notebooks。这一枚举并非口头约定而是硬编码在仓库的 Commitizen 配置中pyproject.toml 的[tool.commitizen]段声明了name cz_conventional_commits、types与scopes列表同时在[tool.commitizen.rules]中通过scope-enum [2, always, [...]]强制 scope 必须落在上述枚举内。也就是说本地 Commitizen 校验与 CI 中的 PR 标题校验共用同一份规则源。2.4 标题书写规则type 与 scope 大小写敏感type 必须小写description 使用现在时态present tensedescription 末尾不加句号description 不得使用 sentence-case、start-case、pascal-case 或 upper-casetype/scope 与描述之间保持严格的type(scope): description冒号加空格格式。合法示例feat(model): add transformer architecture for anomaly detection fix(data): handle corrupted image files during training docs: update installation instructions for Windows chore(ci): migrate from commit message validation to PR title validation2.5 可选 emoji 前缀标题开头可以非必须附加 emoji 以增强可读性技能与 CI 校验都会在验证前剥离 emoji feat(model): add transformer architecture for anomaly detection fix(data): handle corrupted image files during training docs: update installation instructions for Windows chore(ci): migrate from commit message validation to PR title validation推荐映射→feat、→fix、→docs、→style、→refactor、⚡→perf、→test、→build、→chore、→ci。注意 emoji 只是可选装饰不带 emoji 的标题同样有效。2.6 CI 侧的真实校验实现仓库通过可复用工作流 _reusable-pr-title-check.yaml 强制校验 PR 标题其执行逻辑可以印证上述规则安装commitizen4.13.9工作流第 82 行读取github.event.pull_request.title用 Python 正则剥离标题开头的 emoji第 97 行覆盖表情符号、杂项符号、旗帜等多段 Unicode 区间将清洗后的标题写入临时文件执行cz check --commit-msg-file $TEMP_TITLE_FILE第 110 行校验失败时输出详细错误提示格式示例、建议 emoji 等并退出码为 1。该工作流由 pr.yaml 在pull_request事件上调用仅对真实 PR 执行merge group 跳过并且只校验标题而非单个 commit 消息——这与 squash merge 策略完全对应。三、分支命名严格遵循type/scope/description3.1 命名格式分支名必须符合type/scope/description其中 type 与 scope 必须与提交消息中使用的枚举一致即上文的 10 种 type、13 种 scope。合法示例feat/model/add-transformerfix/data/load-image-bugdocs/readme/update-installationrefactor/utils/optimize-performance3.2 pre-commit 层强制分支命名并非只靠人肉自觉。.pre-commit-config.yaml 引入了commitizen-tools/commitizen仓库的commitizen-branch钩子配置在pre-push阶段执行注释明确写道Only enforce branch naming, not commit messages (since we validate PR titles instead)。也就是说推送分支时 pre-commit 就会拦截不合规的分支名从源头保证命名质量。3.3 开发过程与提交流程技能与 CONTRIBUTING.md 允许开发期间使用任意格式的提交例如git add files git commit -m wip: working on transformer model git commit -m fix typo git commit -m address review comments提交 PR 时只需保证标题合规。如需借助 Commitizen 工具可以这样本地校验# 校验单条消息是否符合 conventional 格式 echo feat(model): add transformer architecture | cz check --commit-msg-file - # 校验提交历史 cz check # 依据提交历史生成版本号并更新 CHANGELOG.md cz bump四、质量门禁本地检查与自动化验证4.1 提交前必须执行的两条命令技能明确规定贡献者在最终确定 PR 前需要运行prek run --all-files pytest tests/prek run --all-filespre-commit 的增强封装对所有文件执行仓库配置的全部钩子pytest tests/运行 tests/ 下的完整测试套件单元测试与集成测试其中集成测试在tests/integration/单元测试在tests/unit/。开发环境搭建方式见 CONTRIBUTING.md创建 Conda 环境后通过anomalib install --option dev或pip install -e .[dev]安装开发依赖再执行prek install安装钩子。4.2 pre-commit 钩子清单.pre-commit-config.yaml 完整定义了仓库的质量基线注意其exclude: ^application/即 Anomalib Studio 桌面应用使用独立的 CI 设置钩子版本作用trailing-whitespace/end-of-file-fixerpre-commit-hooks v5.0.0基础格式清理check-yaml/check-added-large-files/debug-statements/detect-private-key同上YAML 校验、大文件拦截、调试语句与私钥检测commitizen-branchcommitizen v4.8.3pre-push 阶段强制分支命名ruff/ruff-formatruff v0.12.0Python lint含--fix自动修复与格式化mypyv1.16.1静态类型检查tests与.semgrep/除外bandit1.8.5安全扫描按pyproject.toml配置运行severity ≥ medium、confidence ≥ high 才报告nbqa-ruffnbQA 1.9.1Jupyter notebook 的 ruff 检查prettierv4.0.0-alpha.8前端与部分文本格式化markdownlintv0.45.0Markdown 文档规范gitleaksv8.30.1密钥/凭据泄漏检测zizmorv1.9.0GitHub Actions 工作流安全审计--min-severity medium --min-confidence high同时 pyproject.toml 中配置了 ruff 与 mypy 的具体规则集审查反馈应始终以这些配置为准而不是审查者个人的口味偏好——这正是技能中Review feedback should align with the projects configured checks inpyproject.tomland.pre-commit-config.yaml的含义。4.3 CI 流水线的构成pr.yaml 是 PR 阶段的编排工作流除标题校验外还并行执行quality通过prek workspace mode同时覆盖库代码src/与application/执行代码风格、类型检查与全部 pre-commit 钩子security复用 _reusable-security-scan.yaml本次 PR 运行semgrep,bandit,zizmor三款工具scan-scope: changed只扫描变更文件severity-level: LOW、confidence-level: HIGH且fail-on-findings: true显式开启失败即拦截unit-tests / integration-tests通过check-paths判断是否涉及库代码路径src/**、tests/**、examples/**、tools/**、pyproject.toml、uv.lock、.pre-commit-config.yaml、tox.ini等单元测试跑在ubuntu-latest30 分钟超时集成测试跑在self-hosted60 分钟超时docker-build当变更涉及application/**或.github/**时构建并上传 Docker 镜像状态汇总 joblibrary-checks-status/docker-build-status聚合各子任务结果任一失败则整体报错阻止合并。工作流还通过concurrency配置了cancel-in-progress: true新提交推送后会自动取消旧运行避免排队浪费。五、安全敏感变更六工具协同审查5.1 安全工具矩阵SECURITY.md 明确了项目采用pre-commit、PR 检查、周期扫描三档安全防线技能要求审查者据此核查安全敏感变更工具类型Pre-commitPR 检查周期扫描CodeQL静态分析Python GitHub Actions✅✅Semgrep静态分析含 Trail of Bits 的 ML 专项规则✅✅BanditPython 静态分析✅✅✅ZizmorGitHub Actions 工作流审计✅✅✅Trivy依赖漏洞与配置错误检查✅Dependabot依赖安全更新✅注意Semgrep 因 不支持 Windows 未纳入 pre-commit因此依赖 CI 层覆盖。5.2 误报抑制规范仓库接受带理由的告警抑制注释见 CONTRIBUTING.md审查者在看到相关注释时应确认其合理性Bandit# nosec BXXX例如import subprocess # nosec B404 # this is actually fineZizmor# zizmor: ignore[rulename]例如uses: actions/checkoutv3 # zizmor: ignore[artipacked] this is actually fineSemgrep# nosemgrep: rule-id例如# nosemgrep: python.lang.security.audit.dangerous-system-call.dangerous-system-call。规则是必须同时说明为什么禁用该规则/为何接受该风险单纯贴注释而不解释不被接受。六、仓库级审查锚点Repo-grounded anchors技能强调审查必须以仓库政策为依据并给出六份锚定文档作为审查时的裁决基准CONTRIBUTING.md —— 贡献总纲含 PR 标题格式、分支命名、开发工作流与 Commitizen 用法docs/source/markdown/guides/developer/contributing.md —— 文档站的贡献指南内容与 CONTRIBUTING.md 同源docs/source/markdown/guides/developer/code_review_checklist.md —— 代码审查清单从代码质量、架构设计、功能正确性、安全、性能、测试、文档注释、兼容性八个维度给出 40 余条检查项.pre-commit-config.yaml —— 质量钩子配置决定prek run --all-files实际执行什么pyproject.toml —— ruff/mypy 规则、Commitizen type/scope 枚举、Bandit 配置等一切工具的规则源SECURITY.md —— 安全策略、漏洞报告渠道与安全工具矩阵。.github/pull_request_template.md 还提供了 PR 模板贡献者需勾选变更类型feature/bugfix/refactor/perf/style/tests/docs/build/CI/chore/security/breaking change并确认已更新文档、已编写测试、标题遵循 conventional commit 格式。七、审查者的期望与严格边界7.1 审查原则具体、可执行、有政策依据反馈应基于仓库策略提出精确的修复建议而非笼统的个人偏好先升级后批准缺少测试、缺少文档、缺少 changelog 条目或存在工作流/安全风险时不得放行高风险区域从严技能明确列出需要更严格审查的文件类别——CLI 入口点CLI entrypoints、CI 工作流workflows、部署相关deployment、推理器inferencers以及面向用户的公开 APIuser-facing public APIs。从仓库结构看这些高风险区分别对应 src/anomalib/cli/、.github/workflows/、src/anomalib/deploy/、src/anomalib/deploy/inferencers/ 等目录改动这些模块时审查者会逐条核对行为兼容性与文档同步。7.2 变更日志要求技能要求 PR 缺失 changelog 条目时发起修改请求。仓库采用 Commitizen 自动生成变更日志pyproject.toml 中update_changelog_on_bump true、changelog_file CHANGELOG.md、changelog_format ## $version ($date)因此合规的 PR 标题是 changelog 质量的前提重大变更还应主动向 CHANGELOG.md 补充摘要。八、审查提问与最终检查清单技能内置了三个标准审查提问可直接用于任何 PR 的快速评估Is the PR title valid for the eventual squash commit?—— 标题在压缩合并后能否直接作为正式提交信息Are branch naming, changelog, tests, and docs in good shape for merge?—— 分支名、变更日志、测试与文档是否都达到合并条件Do the requested changes line up with the projects existing CI and security gates?—— 变更是否与仓库现有 CI 与安全门禁一致最终逐项核对清单与技能一致PR 标题符合 Conventional Commits 格式type/scope 落在 pyproject.toml 枚举内description 为现在时、无句号分支命名符合type/scope/descriptionpre-push 阶段由 commitizen-branch 钩子强制已通过prek run --all-files与pytest tests/CI 的 pr-title-check、quality、security、unit-tests、integration-tests、docker-build 全部通过测试、文档、changelog 齐备且与变更匹配工作流与安全敏感文件CLI、workflows、deployment、inferencers、公开 API已按仓库标准从严审查安全工具Bandit、CodeQL、Semgrep、Zizmor、Trivy、Dependabot无未解决发现误报抑制注释均附带充分的理由说明。结语Anomalib 的 PR 工作流是一条本地 pre-commit → 推送分支校验 → CI 标题/质量/安全/测试 → 人工审查的完整链路而pr-workflow技能的价值在于把这条链路的判定标准显式化标题与分支命名由 pyproject.toml 的 Commitizen 配置统一定义质量基线由 .pre-commit-config.yaml 固化为可执行钩子安全底线由 SECURITY.md 与 pr.yaml 的扫描任务兜底最终由审查者依据 code_review_checklist.md 逐项把关。对照本文梳理的清单逐项自检你的下一个 PR 就能顺畅通过全部门禁安心等待合并。【免费下载链接】anomalibAn anomaly detection library comprising state-of-the-art algorithms and features such as experiment management, hyper-parameter optimization, and edge inference.项目地址: https://gitcode.com/GitHub_Trending/an/anomalib创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考