Keploy 贡献工作流实战客户数据脱敏、Conventional Commits 与 PR/Issue 规范keploy-pr-workflow【免费下载链接】keployOpen-source platform for creating safe, isolated production sandboxes for API, integration, and E2E testing.项目地址: https://gitcode.com/GitHub_Trending/ke/keployKeploy 是一个以“录制真实生产流量并生成 mock”为核心机制的测试平台这意味着任何从仓库或本地环境流出的 fixture、日志、报错输出都可能携带真实客户数据。本文基于 Keploy 仓库内置的贡献工作流技能文档.claude/skills/keploy-pr-workflow/SKILL.md展开完整覆盖其中的客户数据卫生customer-data hygiene红线清单、Conventional Commits 提交规范、PR/Issue 模板要求、破坏性 git 操作禁区与 Issue 提交要素并结合仓库中 commitizen 预提交钩子、DCO 签署文档与keploy sanitize脱敏工具的源码实现加以印证。读完后你将掌握在向 Keploy 仓库提交任何 PR、Issue 或 commit 之前如何系统性地完成数据脱敏自查、写出合规的提交信息并避开不可逆的 git 操作。何时触发这套工作流原文档给出了四条明确的触发场景。当处于以下任一状态时就应该把这套流程当作“离开本机前的检查关卡”即将执行gh pr create、gh pr edit或gh issue create正在撰写一条将落入main分支的 commit message在推送前自查自己写的 diff要把错误输出、日志或样例数据复制进 PR 描述、Issue、测试 fixture 或 README。这四条场景的共同点是内容即将离开本地机器。文档因此把数据卫生定义为“non-negotiable不可谈判”——这是整个工作流的第一优先级。客户数据卫生Keploy 贡献者的一号红线为什么 Keploy 特别强调这一点Keploy 的工作方式是“录制真实用户应用”records real user applications。它的 traces、mocks、recordings 和 logs 天然会携带客户数据带鉴权 token 的响应头、含 PII 的请求体、内部主机名、可以反查到具体用户的 request ID。原文档的要求是在检查之前把每一个 fixture、日志片段、错误 dump 都当作**已污染tainted**对待。这并非抽象的合规口号而是与产品形态直接绑定的风险模型Keploy 的录制产物本身就是客户的完整流量画像。离开机器前的逐项脱敏清单原文档列出了七类必须清洗的内容这里完整继承并逐项说明处理方式凭证Credentials— API key、bearer token、JWT、数据库密码、session cookie、OAuth client secret、AWS/GCP/Azure 密钥。如果某个测试确实需要一个凭证应从环境变量读取文档中使用占位符如sk-xxxxxxxx、Bearer token。内部主机名与 URL—*.internal、*.prod、*.corp、真实公司域名。样例中应使用example.com、httpbin.org或 loopback 地址。非保留网段的 IP 地址— 凡是日志中出现的公网 IP都应假设为可追踪的替换为192.0.2.1TEST-NET-1RFC5737 文档专用网段。原文档的判定标准是只有 RFC1918 / loopback / TEST-NET 三类地址可以保留。用户标识符— 邮箱、用户名、账号 ID、订单 ID、客户姓名。用userexample.com、user-123等替代。Request/Trace ID— 这些 ID 会在可观测性系统中回连到真实流量粘贴进日志前必须打码。真实录制流量— 永远不要提交客户的keploy/test-set-*目录。即便“匿名化”过的录制也往往在路径或时序中留下可识别特征。如果确实需要样例录制应针对samples-go、samples-python等官方样例应用重新生成。生产环境运行的堆栈跟踪— 会泄露文件路径、二进制版本有时还包含内存中的值。原文档最后给出一条判定原则只要你不确定某个东西是否来自客户那它就是。宁可脱敏过度——细节可以补回来但发布出去的内容收不回来you can always add detail back, you cant un-publish。源码印证仓库内置了keploy sanitize自动脱敏工具上述清单中的第 6 类风险提交的 test-set 目录在仓库源码中有对应的自动化防线。CLI 层在 cli/sanitize.go 注册了sanitize子命令其用途描述为 “sanitize the keploy testcases to remove the sensitive data”使用示例为keploy sanitize -t test-set-id该命令进入 pkg/service/tools/sanitize.go 的Sanitize方法其实现要点与 PR 卫生规则直接呼应通过extractTestSetIDs解析-t指定的测试集未指定时处理全部测试集定位./keploy/testSetID目录后若目录中已存在secret.yaml则跳过该测试集说明已经脱敏并抽取过密钥对测试集内文件执行 gitleaks 风格的密钥检测RedactYAML会把检测到的密钥从 YAML 中原位替换为占位符同时将真实值集中写入keploy/set/secret.yaml见 pkg/service/tools/sanitize.go。这意味着“密钥从 fixture 中剥离、集中管理”正是工具化的标准动作而贡献者手写 fixture 时也应遵循同一原则从环境变量读取、文档中留占位符。检测规则由仓库内嵌的自定义 gitleaks 配置 pkg/service/tools/custom_gitleaks_rules.toml 提供其中包含 AWS Access Key、AWS Secret Key、GitHub PAT / OAuth / App Token 等规则AKIA[A-Z0-9]{16}、ghp_[0-9a-zA-Z]{36}等正则覆盖了卫生清单第 1 类“凭证”的常见形态。此外仓库的 .gitignore 已经将keploy、keploy.yml、keploy-logs.txt、keploy-config.yaml等录制/运行产物列入忽略清单从版本控制层面堵住了“误提交客户 test-set”的通道。Commit Message 规范Conventional Commits commitizen DCO 签署格式与强制机制原文档规定的格式为type(scope): subject即 Conventional Commits 规范且由 commitizen 通过.pre-commit-config.yaml在提交时强制校验。仓库中的实际配置印证了这一点.pre-commit-config.yaml的全部内容repos: - hooks: - id: commitizen stages: - commit-msg repo: https://github.com/commitizen-tools/commitizen rev: v2.21.2钩子挂在commit-msg阶段意味着不符合规范的提交信息会在本地被拦截。而.cz.toml进一步把约定固定下来[tool.commitizen] name cz_conventional_commits version 0.2.4 tag_format v$version允许的 type 有feat、fix、docs、style、refactor、test、chore。仓库的 AGENTS.md 在 “Commit hygiene” 一节重申了同一套规则并补充了执行细节可作为规范的第二出处.pre-commit-config.yaml接入 commitizenConventional Commits.cz.toml将约定锁定为cz_conventional_commitstype 使用feat:、fix:、chore:、refactor:、test:、docs:每个 commit 都必须有正文空一行后写一段“改了什么、为什么改”。三条写作规则主题行用现在时、祈使语气写fix: resolve null pointer on test-set reset而不是fixed/fixes。正文强制存在主题行后空一行再写一段描述what changed and why。原文档特别强调即便是单行小改动正文也是必选的。用git commit -s签署让 git 从配置中读取身份生成Signed-off-by尾注不要手工拼写trailer——手写的Signed-off-by与 author 不一致是常见的签署失败原因。DCO 背景签署要求并非该技能文档的发明而是仓库贡献协议的硬性条款。.github/CONTRIBUTING.md 的 “Signing-off on Commits (Developer Certificate of Origin)” 一节要求所有贡献者对每个 commit 接受 DCO 声明并给出同样的操作示例$ commit -s -m my commit message w/signoff文档还建议在~/.gitconfig中设置别名让所有提交默认带签[alias] amend commit -s --amend cm commit -s -m commit commit -s并要求使用真实姓名与可达邮箱不接受匿名贡献。这与技能文档中 “dont hand-construct theSigned-off-bytrailer” 的要求互为表里-s保证 tailer 与 git 配置中的 author 一致从而通过 DCO 检查。PR/Issue 标题与正文跟随当前仓库的模板原文档对此给出的核心规则只有一句PR/issue 的模板应该与你正在工作的仓库中实际使用的模板保持一致。对于 Keploy 主仓库当前生效的 PR 模板是.github/PULL_REQUEST_TEMPLATE.md。提交 PR 时应完整填写其结构主要包括Describe the changes that are made— 变更描述Links References— 包括Closes: #issue number极小改动可写 NA、相关 PR、相关 Issue、相关文档What type of PR is this?— 勾选类型Chore / Feature / Bug Fix / Documentation / Style / Refactor / Performance / Test / CI / RevertAdded e2e test pipeline?— 是否新增了端到端测试流水线可勾选 “no, because they arent needed” 并说明Self Review done?、文档更新、测试步骤、截图/日志等自检项PR 标题与分支命名的语义约定— 模板给出示例PR 标题如fix: patch MongoDB document update bug分支名如feat/#1-login-flow要求遵循 Keploy 的 PR/分支语义约定。注意一个与 commit 规范一致的细节模板里的 PR 标题示例fix: patch MongoDB document update bug正是 Conventional Commits 形式说明 commit 规范与 PR 标题规范在 Keploy 中是同一套语义体系的两层落地。Issue 模板则位于.github/ISSUE_TEMPLATE目录提交 Issue 时按其中的字段填写不要自创格式。破坏性 git 操作禁区原文档第 4 节划定了一条明确的红线以下操作未经用户明确批准一律不得执行操作禁止原因从风险角度向main或任何共享分支执行git push --force直接覆盖他人已发布的历史不可逆在有未提交工作的分支上执行git reset --hard/git clean -fd永久丢失未落盘的工作用git branch -D删除非自己创建的本地分支可能删掉他人未合并的工作分支跨其他贡献者已发布的 commit 做 rebase改写共享历史破坏所有人的本地状态文档给出的原则是“拿不准就问When in doubt, ask”——破坏性操作的确认成本极低但撤销成本极高。这条规则对使用 AI Agent 协作的贡献者尤其关键Agent 在自动化流程中默认不应执行上述任何一条。Issue 提交规范四要素 复现录制在向 Keploy 仓库提交 Issue 或在他人 Issue 下评论时原文档要求同样的客户数据规则适用— 粘贴日志前先按前文的脱敏清单清洗提交内容必须包含四个要素Keploy 版本keploy --version的输出操作系统与架构OS/arch你执行的确切命令该问题在 Docker 与原生native两种运行方式下是否都能复现。附带的复现录制必须重新生成— 如果要贴一份录制来复现问题必须针对公开样例应用如samples-go、samples-python重新录制永远不要附带客户真实的 test-set。其中keploy --version命令在源码中对应 main.go 处设置的版本标识符utils.VersionIdentifier versionkeploy二进制本身即以 CLI 形式暴露该子命令Issue 作者可直接复制输出。Keploy 对 Docker 与原生两种方式分别支持两者在录制机制上有差异见 AGENTS.md 的兼容矩阵因此“是否两边都能复现”是区分“环境问题”与“代码缺陷”的关键分诊信号。与 keploy-e2e-test 技能的衔接原文档末尾声明了与另一技能keploy-e2e-test的关联keploy-e2e-test— 在开 PR 之前先针对真实样例应用验证行为变更。该技能定义于.claude/skills/keploy-e2e-test/SKILL.md其要点是用源码构建 Keploy 二进制与 CI 相同的go build命令在官方样例应用上跑真实的 record → replay 流程以reports/test-run-*/test-set-*-report.yaml全部status: PASSED作为验证标准。两个技能构成一条完整的贡献流水线e2e 验证行为变更keploy-e2e-test │ ▼ 数据脱敏自查 合规 commit 模板化 PRkeploy-pr-workflow │ ▼ push / gh pr create即先用 e2e 证明“变更是对的”再用 pr-workflow 保证“离开本机的内容是无害且合规的”。提交前自检清单综合提炼将原文档各节规则合并为一份可直接执行的 checklistdiff 与粘贴内容是否按七类清单完成脱敏凭证、内部域名、公网 IP、用户标识、request ID、客户 test-set、生产堆栈是否确认没有提交keploy/test-set-*目录或其中的任何文件必要时可用keploy sanitize先做工具化脱敏commit message 是否为type(scope): subject形式type 属于feat/fix/docs/style/refactor/test/chore主题行是否现在时祈使语气正文空行 一段 what why是否存在是否使用git commit -s由 git 生成Signed-off-byPR/Issue 是否遵循当前仓库模板.github/PULL_REQUEST_TEMPLATE.md/.github/ISSUE_TEMPLATEIssue 是否包含keploy --version、OS/arch、确切命令、Docker vs 原生复现情况四项是否未执行任何需要显式批准的破坏性 git 操作行为类变更是否已先用 e2e record/replay 验证参见keploy-e2e-test技能这套工作流的本质是把“Keploy 会接触真实客户数据”这一产品事实转化为贡献者侧的强制性操作规程规范落在.claude/skills/keploy-pr-workflow/SKILL.md机制落在 commitizen 钩子.pre-commit-config.yaml、DCO 签署.github/CONTRIBUTING.md与 sanitize 工具cli/sanitize.go上二者共同保证进入main分支与公开 Issue 区的内容既合规又安全。【免费下载链接】keployOpen-source platform for creating safe, isolated production sandboxes for API, integration, and E2E testing.项目地址: https://gitcode.com/GitHub_Trending/ke/keploy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
