Prowler 开源仓库 Pull Request 提交规范与实战指南模板、Conventional Commits 与 CI 门禁全解析【免费下载链接】prowlerProwler is the world’s most widely used open-source cloud security platform that automates security and compliance across any cloud environment.项目地址: https://gitcode.com/GitHub_Trending/pr/prowler本篇指南基于 Prowler 仓库内置的 AI 技能文档 skills/prowler-pr/SKILL.md系统讲解在 Prowler 多组件 monorepoSDK、API、UI、MCP Server中创建高质量 Pull Request 的完整流程从分析变更、按模板填充、遵循 Conventional Commits 标题约定到通过 changelog 门禁、冲突检查与代码评审再请求机制。读完本文你将能够用ghCLI 与 git 命令一次通过 CI 校验地提交符合项目规范的 PR。PR 创建流程总览skills/prowler-pr/SKILL.md将 PR 创建归纳为四步核心流程配合仓库中的真实 CI 工作流构成一条从本地分支到合并的完整链路分析变更执行git diff main...HEAD理解分支上相对main的全部提交内容确定受影响组件判断变更落在 SDKprowler/、APIapi/、UIui/、MCPmcp_server/还是 Docsdocs/这一步直接决定 changelog 碎片文件写到哪里按模板填充各小节以 .github/pull_request_template.md 为骨架填写 Context、Description、Steps to review、Checklist创建 PR使用gh pr create提交标题遵循 Conventional Commits 约定。仓库的pr-conflict-checker.yml与pr-check-changelog.yml会在 PR 创建后自动接管校验因此第 1、2 步做得越细致后续被 CI 打回重做的概率越低。理解 Prowler 的多组件结构Prowler 是一个包含多个独立交付组件的仓库每个组件有自己独立的目录、CHANGELOG.md与changelog.d/碎片目录见下表源自 SKILL.md 与 skills/prowler-changelog/SKILL.md 的交叉验证组件源码目录Changelog 碎片目录编译产物SDK/CLIprowler/prowler/changelog.d/prowler/CHANGELOG.mdAPIapi/api/changelog.d/api/CHANGELOG.mdUIui/ui/changelog.d/ui/CHANGELOG.mdMCP Servermcp_server/mcp_server/changelog.d/mcp_server/CHANGELOG.md从源码结构看仓库根目录的uv.lock与pyproject.toml被归入 SDK 组件——pr-check-changelog.yml中明确将这两个根级依赖文件与prowler/changelog.d/碎片绑定见 .github/workflows/pr-check-changelog.yml 中root_deps_changed逻辑。PR 模板结构每个小节该写什么PR 模板的实际文件位于 .github/pull_request_template.mdSKILL.md 与之一致。创建 PR 时必须完整填充以下小节Context写清楚为什么做这个变更动机与背景若该 PR 修复某个 issue使用Fix #XXXX语法建立 issue↔PR 关联。仓库的 changelog 编译规则规定编译产物中的条目只允许带 PR 链接issue 与 PR 的映射关系正是通过这里的Fixes #N完成的。Description总结变更内容与所依赖的其它改动dependencies。要点是改了什么而不是为什么改——动机属于 Context。Steps to review给出审阅者如何验证此变更的具体步骤复现路径、测试命令、预期行为等帮助 reviewer 快速进入状态。Checklist模板清单分为两层可折叠的Community Checklist与按组件展开的检查项。完整内容源自 .github/pull_request_template.md### Checklist details summarybCommunity Checklist/b/summary - [ ] 该 feature/issue 是否已列在项目的 open issues 或 roadmap 中 - [ ] 是否已分配给本人若未分配请通过 issue/feature 渠道或社区 Slack 申请 - [ ] 已检查 open pull requests确认没有已存在的 PR 实现相同结果 /details - [ ] 检查代码是否有测试覆盖 - [ ] 检查代码是否遵循 Google Python Style Guide 的注释与 Docstring 规范 - [ ] 检查是否需要 backport回溯到维护分支 - [ ] 检查是否需要修改 README.md - [ ] 如适用确保在 组件/changelog.d/ 下添加 changelog 碎片SDK/CLI 专属PR 是否包含新检查check若是是否需要为对应云厂商更新权限permissions——SKILL.md 特别强调请仔细审查此项。权限模板位于 permissions/ 目录例如 AWS 的prowler-additions-policy.json与 Azure 的prowler-azure-custom-role.json。UI 专属如适用- [ ] 所有 issue/任务需求在 UI 上按预期工作 - [ ] 若新增或更新 npm 依赖附上包健康度证据维护状况、流行度、已知漏洞、许可证、发布年龄并说明为何现有/原生方案不足 - [ ] 功能流程截图/视频 - Mobile (X 640px) - [ ] 功能流程截图/视频 - Tablet (640px X 1024px) - [ ] 功能流程截图/视频 - Desktop (X 1024px) - [ ] 确保在 ui/changelog.d/ 下添加 changelog 碎片API 专属如适用- [ ] 所有 issue/任务需求在 API 上按预期工作 - [ ] 端点响应输出如适用 - [ ] 新增/修改的查询或索引的 EXPLAIN ANALYZE 输出如适用 - [ ] 性能测试结果如适用 - [ ] 其它相关实现证据如适用 - [ ] 验证是否需要重新生成 API specs - [ ] 检查是否需要版本更新如 specs、uv 等 - [ ] 确保在 api/changelog.d/ 下添加 changelog 碎片MCP Server 专属- [ ] 所有 issue/任务需求在 MCP Server 上按预期工作 - [ ] 确保在 mcp_server/changelog.d/ 下添加 changelog 碎片LicenseBy submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.组件特定规则速查SKILL.md 给出了按组件区分的额外检查点与模板中的组件小节一一对应组件Changelog 碎片目录额外检查SDKprowler/changelog.d/新增检查 → 是否需要更新云厂商权限APIapi/changelog.d/API specs、版本升级、端点输出、EXPLAIN ANALYZE、性能测试UIui/changelog.d/Mobile/Tablet/Desktop 三端截图MCPmcp_server/changelog.d/无额外要求创建 PR 的完整命令集SKILL.md 提供了从分支检查到创建 PR 的完整命令链# 检查当前分支状态 git status git log main..HEAD --oneline # 查看完整差异 git diff main...HEAD # 用 heredoc 填充正文创建 PR gh pr create --title feat: description --body $(cat EOF ### Context ... EOF ) # 创建草稿 PR gh pr create --draft --title feat: description其中git diff main...HEAD的三点语法表示对比main与当前分支的共同祖先到当前分支的差异确保只展示本分支独有的变更——这与 SKILL.md 分析 main...HEAD 以理解全部提交 的要求一致。标题约定Conventional CommitsSKILL.md 要求 PR 标题遵循 Conventional Commits 规范允许的前缀为feat:新功能fix:缺陷修复docs:文档chore:维护refactor:代码重构test:测试这一约定并非软性建议而是被 CI 强制执行。在 .github/workflows/conventional-commit.yml 中agenthunt/conventional-commit-checker-action使用如下正则校验 PR 标题^(feat|fix|docs|style|refactor|perf|test|chore|build|ci|revert)(\([^)]\))?!?: .这意味着前缀取自feat|fix|docs|style|refactor|perf|test|chore|build|ci|revert之一比 SKILL.md 列的六类更全还包含style、perf、build、ci、revert可选的(scope)作用域如feat(aws): ...可选的!表示破坏性变更前缀与描述之间必须用:冒号加空格分隔描述不能为空。该工作流仅在 PR 目标分支为master或v5.*时触发事件类型为opened、edited、synchronize——也就是说修改 PR 标题也会重新触发检查。参考仓库中的真实示例changelog 编译 PR 使用chore(changelog): vX.Y.Z这样的标题。Changelog 门禁pr-check-changelog 工作流PR 的 changelog 要求由 .github/workflows/pr-check-changelog.yml 强制执行规则如下与 SKILL.md 一致必需触及ui/、api/、mcp_server/、prowler/任一目录的 PR必须在对应changelog.d/下新增或修复碎片文件文件名校验碎片文件名必须匹配正则^[A-Za-z0-9][A-Za-z0-9._-]*\.(added|changed|deprecated|removed|fixed|security)(\.[0-9])?\.md$类型取值与 keepachangelog 章节一一对应added、changed、deprecated、removed、fixed、security内容 lint碎片内容中禁止手写 PR 或 issue 链接匹配[(#N)]、#N或github.com/.../(pull|issues)/N都会被拒绝因为链接会在发布编译时由 git 历史自动解析附加禁用直接编辑常规 PR 直接修改CHANGELOG.md会被拒绝——只有已发布版本的拼写修正等例外场景允许且需加no-changelog标签跳过添加no-changelog标签可跳过校验仅限纯文档、纯 CI 变更等场景需谨慎使用。工作流还会自动在 PR 上发布/更新一条状态注释标记!-- changelog-check --并在缺失或非法时以exit 1使检查失败。碎片文件的正确创建方式见 skills/prowler-changelog/SKILL.mdecho 条目文本描述这次变更 组件/changelog.d/slug.type.md例如新增 AWS Security Hub 检查echo securityhub_delegated_admin_enabled_all_regions check for AWS provider prowler/changelog.d/securityhub-delegated-admin.added.md碎片正文规则只写条目文本、单行、结尾换行、句末不加句号、不要以冗余动词开头章节标题已提供动作语义、不要写 PR 链接。判定受影响组件的辅助命令git diff master...HEAD --name-only | grep -E ^(ui|api|mcp_server|prowler)/ | cut -d/ -f1 | sort -u一个 PR 可以按需添加多个碎片每个条目一个文件例如同时包含kms-rotation-check.added.md与kms-disabled-keys.fixed.md同一类型多条时使用不同 slug 区分。其它配套 PR 检查工作流除 changelog 门禁外仓库还为 PR 配置了多个自动化检查均可从 .github/workflows/ 查看冲突检查pr-conflict-checker.yml检出 PR head SHA扫描所有变更文件中是否残留冲突标记conflict markers避免带着未解决的 merge conflict 提交自动打标labeler.yml基于变更文件自动应用标签并为社区贡献者非组织成员的首次 PR 添加community标签评审所有权CODEOWNERS.github/、Makefile、kubernetes/、所有Dockerfile与docker-compose*归prowler-cloud/platformSDK/prowler/、/tests/、/dashboard/、/docs/等、API、UI、MCP 均归prowler-cloud/engineering——提交 PR 前可以据此预判会被哪个团队 review此外还有sdk-tests.yml、api-tests.yml、ui-tests.yml、ui-e2e-tests-v2.yml等组件测试与安全扫描工作流共同构成 PR 的完整质量闸门。创建 PR 前的五步自检SKILL.md 要求创建 PR 前逐一确认✅ 本地全部测试通过SDK 使用make testpytest -n auto -vvv -s --cov./prowler --cov-reportxml tests见 MakefileMCP 使用make test-mcp✅ Lint 通过make lint一键执行全部组件 lintSDK 走flake8black --checkpylintAPI 与 MCP 走ruff checkruff format --check与 CI 完全一致✅ 已添加 changelog 碎片如适用见上文门禁规则✅ 分支已与main保持同步✅ 提交信息干净、具有描述性。make lint的实现细节源自 Makefile 第 61-85 行lint是lint-sdk、lint-api、lint-mcp的组合目标其中 SDK 组件通过uv run执行 flake8忽略E266,W503,E203,E501,W605,E128、black 检查与 pylintAPI/MCP 各自在组件目录内执行 ruff 检查与格式校验。重新请求 Review 前处理评审线程必需SKILL.md 特别强调在重新请求 review 之前必须解决或回应每一条未关闭的 inline review 线程这是强制要求而非建议同意并已修复提交修复并以 commit hash 回复审阅者便于快速验证例如Fixed in abc1234.同意但延后说明为何超出本 PR 范围以及记录在哪里跟踪不同意给出清晰的技术理由进行回复不允许让线程静默悬挂重新请求 review仅在所有线程处于干净状态已解决或已明确回应之后进行。经验法则源自 SKILL.md审阅者重新打开 PR 时绝不应该产生他们到底看没看到我的评论的疑问。总结Prowler 的 PR 提交流程是一套模板 约定 CI 门禁三位一体的工程实践模板.github/pull_request_template.md保证信息完整Conventional Commitsconventional-commit.yml统一标题语义changelog 碎片机制pr-check-changelog.yml skills/prowler-changelog/SKILL.md让并发 PR 互不冲突CODEOWNERS与多工作流则自动分配评审责任。按照本文的流程操作即可提交一份结构完整、一次通过 CI 校验、便于评审的高质量 PR。更多 PR 约定与流程细节可参考仓库的开发者指南 docs/developer-guide/introduction.mdxSending the Pull Request 章节以及 skills/prowler-pr/references/pr-docs.md。【免费下载链接】prowlerProwler is the world’s most widely used open-source cloud security platform that automates security and compliance across any cloud environment.项目地址: https://gitcode.com/GitHub_Trending/pr/prowler创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考