nathank
(Nathan Kershaw)
24
这件事有进展了吗？虽然我很喜欢定期活动的功能，但不得不频繁地手动管理活动归档，真的让我很头疼！
2 个赞
Ethsim2
(Ethan )
25
目前该 PR 似乎还没有进一步的可见进展：
我仍然希望这个功能能包含在捆绑的 Events 插件中，而不是需要单独维护。
之前的这段经历也是为什么我对长期在本地维护这个功能持谨慎态度的原因之一。
在我自己的自建环境中，我已经使用了一个 after_code 钩子来进行一个小上游 PR 的回移（backport）。该钩子首先检查标记，以确认该功能是否已在上游落地。如果没有，它会下载已知提交的补丁，运行 git apply --check，然后才使用 git apply 应用它。
只要补丁与核心代码保持匹配，这种方法运行得还算不错，但我之前已经遇到过早期版本的回移在核心代码更新后无法应用的情况。随后重建失败，容器保持离线状态，直到我移除了该钩子。
对于这项特定的更改，如果我需要一个临时的后备方案，我可能会以同样的方式提供一个 after_code 回移，而不是将其打包为单独的插件。
原因是 #43187 已经修改了捆绑的 Events 插件自身的服务器端定期滚动（rollover）路径。after_code 钩子可以在重建期间直接应用基本上相同的上游补丁。而单独的插件则需要通过扩展点（extension point）重新创建该集成，或者以其他方式前置/覆盖内部 MonitorEventDates 的行为，这会增加另一层复杂性，并且可能同样脆弱。
after_code 方法的缺点是它仍然依赖于上游代码的确切结构。由于后继主题（successor-topic）行为涉及 MonitorEventDates，只要 git apply --check 成功，就可以继续使用针对同一固定提交的补丁。如果上游对该代码的更改足以导致补丁上下文不再匹配，我就需要将更改变基（rebase）或适配到当前的 main 分支，创建一个新的提交，并更新钩子以使用新的提交 SHA。
因此，我的偏好仍然是：
- 将后继功能合并到捆绑的 Events 插件中；或者
- 如果团队希望该行为保持外部化，则围绕定期活动滚动暴露一个受支持的钩子。
在此之前，after_code 补丁将是一个实用的临时自建后备方案，但我不会认为它是理想的长期分发机制。
3 个赞