描述错误
在我们的一个存储库中，当我们预计不会发生部署时，我们会看到一致的部署。 当@renovatebot发出更新依赖项的拉取请求时，特别会发生这种流失，因此_可能_是它处理提交/合并过程的方式。
这是一个示例 PR ，其中存在无发布标签（在我们的示例中Version: Trivial ），但发布仍在发生。 这是给定合并的CI 结果。
@hipstersmoothie有机会时，我会以详细模式运行进行更新。 如果我能把它追到一些特别的东西，我会打开一个 PR。
再现
我还没有完全确定这里的共性是什么。 这是我们组织中@renovatebot自动合并代码更新的唯一地方，因此它可能与此相关。
预期行为
不应触发任何释放。
zephraph
所有11条评论
在不同的 repo 上有另一个实例。 https://github.com/artsy/palette/compare/v2.25.10...v2.25.11。 这也是自动合并的，但是危险而不是@renovatebot。 也许这就是机器人合并 PR 的方式？
zephraph
于 2019-01-15
它可能是。 跳过释放标签要求头部具有相关的标签。
它应该寻找可能寻找最后一个 PR 而不是最后一次提交。
hipstersmoothie
于 2019-01-15
hipstersmoothie
于 2019-01-15
嗯……是的。 所以，当我构建它时，我查看了上一个版本的头部哈希和哈希，并用它来找出 PR 是什么。
https://github.com/artsy/reaction/pull/1407/files#diff -ff397bdd24eed50e2a2cade2792a9d80R100
zephraph
于 2019-01-15
@zephraph只是要清楚，这是正在发生的情况吗？
日志：
- 有些人在合并后提交了机器人或人
- 具有带有
skip-release标签的 PR 的提交
结果：
auto 没有skip-release因为 commit 2 不在 gitloh 的顶部
hipstersmoothie
于 2019-01-17
合并后没有提交。 似乎是合并本身。 当机器人合并（我认为是这样，但这可能是巧合）时，即使存在skipReleaseLabels标签，也会发布 PR。 如果需要，我可以找到更多示例。
这是最新的示例（类似于上面的示例）。
- https://github.com/artsy/renovate-config/pull/164由 renovate 创建
- 翻新分配给 PR（在skipReleaseLabels 中）的
Version: Trivial - Renovate 自动合并 PR
- 尽管存在
skipReleaseLabels标签，但新版本仍被删减
zephraph
于 2019-01-17
此 PR 合并在提交主题中没有 PR 编号
所有有工作的人都有一个 PR 号码
auto依赖于提交消息中的这个数字来获取 PR 号：
所以在合并这些 PR 时似乎有些事情发生了。 这是正在发生的变基吗？
hipstersmoothie
于 2019-01-17
我们需要一个返回与 SHA 关联的 pr 的函数，但我找不到合适的 octokit 方法
hipstersmoothie
于 2019-01-18
嗯，只是尝试将 master 中的提交与 PR 中的提交相匹配，但似乎具有不同的 SHA。
这是超级令人失望的。 现在我不知道我们如何将这些提交与他们的 PR 相匹配
hipstersmoothie
于 2019-01-18
merge_commit_sha来救援
hipstersmoothie
于 2019-01-18
@zephraph这应该在v2.5.6修复。 如果您还有问题，请告诉我！
hipstersmoothie
于 2019-01-18
相关问题
jdalrymple
·
6评论
aleclarson
·
14评论
zephraph
·
12评论
theAdhocracy
·
6评论
hipstersmoothie
·
11评论
最有用的评论
@zephraph这应该在
v2.5.6修复。 如果您还有问题，请告诉我！