我有一个案例，我需要将提交包含在semantic-release/commit-analyzer但不包含在semantic-release/release-notes-generator. 是否可以在 Github 动作语义发布中做到这一点？
问问题
237 次
1 回答
0
Semantic-release 将仅（默认情况下）包含在发行说明中触发发布的提交。所以提交，例如开始ci:或refactor:不通过。*我认为这是你的用例——一个自动提交，它会触发一些动作，但它本身并不构成发布。
更新它似乎你真的想触发版本碰撞而不记录你做了什么。我认为这是一个坏主意（在下面展开），但可以使用这样的 hack：
静默提交
语义发布的全部意义在于记录每个值得版本更新的更改。但是，如果您真的想产生隐藏的凹凸，则可以使用以下方法的破解：
- 将最新标签保存到 var 或文件
- 在没有操作的情况下运行语义发布
@semantic-release/github，但使用@semantic-release/changelog操作，将更改日志写入 git 发布不会拾取它的地方，即在克隆目录之外。 - 运行一个自定义脚本：
- 解析你的 changelog.md
- 获取最新的发行说明（简单：按标题解析）
- 检查您是否已发布，即第一个标题标签是否不是您在步骤 1 中获得的标签。
- 去掉“坏”线
- 输出到标准输出（重定向到 var）或写入某处
- 如果有一些输出，请自己创建 github 版本，使用各种操作之一，并将消息设置为脚本的输出。
不这样做的理由
我只是互联网上的一个随机人，但我认为这不是一个好主意。推理：
语义发布的全部意义在于使发布“无聊且不浪漫”：更具体地说，每个值得发布的提交都会触发文档化发布。现在要么你的自动fix: stuff提交确实修复了一些东西（在这种情况下这是值得注意的，应该包括在内），或者它没有，在这种情况下你有一些其他问题（也许你试图发布'浪漫和有趣'的原因? 也许你需要每 n 天发布一次，即使实际上没有任何改变？）。在任何一种情况下，隐藏一个合法的修复都不是解决问题的方法。
如果您的问题是一种应该生成发布的“微修复”，但发生频率太高以至于阻塞了发布说明，您可能需要一个预发布分支（在合并提交中，许多微修复被汇总到一个大修复中）。
*假设您使用的是常规提交
于 2021-09-27T10:12:24.347 回答