README

👷 进行中！请参阅README底部的“状态”

Patchwatch将报告项目应用到的组件补丁。它的目标是提供补丁的可见性，以便您可以查看如下信息：

• 我们正在修补哪些消费组件（例如Composer或NPM包）？
• 哪些项目正在使用哪些补丁？
• 每个应用补丁的上游问题是什么？
• 上游工作的状态如何？我们应该在哪里集中精力以有效？
• 我们的本地项目是否应用了每个补丁的相同版本？

汇总信息后，您可以查看一个报告，该报告显示您正在修改的组件、相关的上游问题和您本地哪些补丁使用了哪些补丁。跨项目的可见性有助于您的团队了解项目所需的补丁，而来自上游问题的丰富数据可以帮助您集中精力并指导您的贡献/更新工作。

这是一个针对机构或网站集的工具。如果您正在管理多个类似的项目代码库（例如网站代码库），并且在构建过程中应用补丁到消费组件，那么了解这些项目使用的补丁可能具有相似性可能对您感兴趣。

问题

• 我们有多个项目共享一个公共平台和组件。
• 当发现问题时，我们通过补丁或MR向平台和组件贡献修复。
• 其他项目可能重复工作，以识别相同的问题并发现解决方案。
• 共享补丁是好的。

解决方案

• 将我们补丁使用的相关信息捕获到一个公共存储库中。
• 确定方法中的共性。
• 揭示前进的机会。
• 自动化这个过程。

实现

1. 从cweagans/composer-patches源处理补丁。
2. 在我们的已知补丁存储库中搜索匹配项。
3. 如果没有匹配项，则创建一个新条目。
4. 记录当前项目对补丁的使用情况。

关于此的一些说明

1. https://gist.github.com/xurizaemon/4b1539fd2bbf570bd8149a933ad8fcbe
2. 我们运行哪些补丁？
3. Patchwatch进度报告

计划

解析器

• cweagans/composer-patches补丁文件
• Drush make
• Composer lock（能否读取cweagans/composer-patches补丁？）
• 补丁目录...
• Node patch-package（例如Mahara补丁，包括上述内容加上此过滤器）
• gem-patch?

通知者

转换器？我不知道 - 无论如何，丰富补丁URL的数据，以便我们可以根据补丁详情看到例如Github/Gitlab/Drupal/...问题状态。

• Drupal
• Github
• Gitlab

存储后端

• Gitlab
• Gist
• 目录

输出

• 这个的初步原型是按照补丁组件排列的，然后是每个问题的ID。
• 除了按项目查看顺序排序外，没有进行排序。
• 也可以按项目分组 - 但看到多个项目针对一个补丁是有趣的，特别是当
• Markdown报告如composer-lock-diff会更好

更多...

• 支持更多解析器（例如其他项目的补丁）
• 支持存储/发现的其他后端
• 基于组件使用建议修改方案

安装（开发者版）

1. git clone git@gitlab.com:xurizaemon/patchwatch.git
2. composer install
3. ./bin/patchwatch

该命令最终将以.phar格式打包，便于使用。

如果你使用Lando，有一个.lando.yml文件，其中包含一个已知良好的环境和一些有用的命令。

测试

在tests/src目录中有PHPUnit测试覆盖率。

贡献

本项目使用semantic-release。建议使用常规提交格式的提交信息，但无需过于担心，我们可以在合并请求（MR）中修正。

状态：进行中

此工具处于早期开发阶段。实现了一些简单的命令来分析补丁源。代码库的结构可能会演变。已有初步测试覆盖率，欢迎提供输入或贡献。

发音

发音为 pɔtʃ wætʃ。感谢阅读此说明！