您好，
我们需要在电子邮件中使用此新功能/特性：
由于它尚未合并（我们假设它有一天会合并），那么在生产环境中运行 Discourse 并包含一个正在审查的 PR 的推荐方法是什么？
我假设我们必须避免/不更新 Discourse 的常规更新，但这可能过于简化了方法。
如果您能就其他人在此场景下如何工作提供任何指导，我们将不胜感激。
- Jake
首先：我不知道。
但我认为这可能会奏效：
cd /var/discourse
./launcher enter app
cd /var/www/discourse
su - discourse -c 'git fetch origin pull/<pr_number>/head:<local_branch_name>'
su - discourse -c 'git switch <local_branch_name>'
sv restart unicorn
如果奏效，那么你可以在 app.yml 中添加内容，使其在构建过程中执行此操作。或者也许它很快就会被合并，你只需要等待。
如果这让情况变得更糟，你可以执行
./launcher destroy app;./launcher start app
这将恢复你上次构建的映像。
3 个赞
这非常有帮助，谢谢。理想情况下，我们希望等到它被合并，但由于是新手，不清楚这需要几天、几周还是几个月。
再次感谢。
此 PR 没有任何批评意见（我没有详细查看），但总的来说，我认为这不是一个好的做法。
- 当您停留在该分支上时，您将无法从核心获得任何更新，其中包括任何安全补丁。
- 分支中的更改可能会导致一些不稳定（在合并之前必须将其视为开发代码）。
- 如果它被拒绝了，您该怎么办？
- 甚至连测试都还没有运行？
利用 CDCK 开发人员审查，等到审查和合并后再进行？
5 个赞
这是个好建议。
根据我的建议，你也许能看到它确实有效（或者其中有回答这个问题的规范），或者在它被接受之前先暂时用着。很多人等几周（甚至几个月）才升级。
2 个赞
@merefield 谢谢 - 我认为你的意思是等到它合并，对吗？
我们同意，这是一个很棒的主意。但在此期间，我们需要处理电子邮件退信。
同样，我们不知道这个过程需要多长时间，所以没有这些信息，我们将假设它需要相当长的时间。
也许我遗漏了什么细微之处……
我认为你可以安全地试用几周。如果发布了另一个版本，你可以决定是否更新你的 PR 以便与下一个版本一起使用，或者寻找其他解决方案。也许最简单的方法是将其放入插件中？
等等。为什么不直接将其放入插件中？
这是通常的做法。将其放入插件中，然后询问他们是否有兴趣进行 PR。目前，似乎你是这个星球上唯一想要这个的人。将其添加到核心意味着有人必须无限期地维护它；这并非易事。
3 个赞
是的，我不明白为什么这没有在插件中实现。
然后，您可以独立于核心安装来演进插件。
一旦（如果）PR 被合并，您就可以删除该插件！
1 个赞
我们也需要为非公开的安全补丁解决此问题。
我们在内部工具中有一个从存储库合并分支的代码——我建议您也采用相同的方法。
类似这样的代码应该可以在 exec 块中（可能在 after_code 挂钩中）为您工作：
# 获取并合并补丁
git merge REFERENCE --no-commit
bundle install # 如果需要
pnpm install --frozen-lockfile # 如果需要
5 个赞
@merefield @pfaffman 这不是一个插件，因为对我们来说，这并不容易。我们从未写过插件。如果有人知道如何连接它，我们很乐意看看！
另外，我可能不会说我们是唯一“想要”netcore 的人——它是地球上最大的 ESP 之一……比核心中支持的其他一些 ESP 大很多倍。我并不是说它更好，或者用户可能想要其他的，但 netcore 是一个非常大、备受推崇的 ESP。事实上，你可以在这里看到很多关于它的讨论，因为它以前是 pepipost：
2 个赞
我觉得双重策略是合适的：
- 现在就将此构建为插件，然后上线
- 与 CDCK 协商/讨论 PR
无法构建插件并不是 PR 的充分理由。
第三方仍然可以使用您的插件。
5 个赞
@merefield 抱歉，您为什么认为插件构建与 PR 创建有关？Netcore 自己编写了 PR。
也许我遗漏了您所说的一些细节。
1 个赞
只是一个建议。它让您在部署时间表上拥有更大的灵活性。谁不喜欢更少的依赖项？
2 个赞
因为您可以创建一个插件。
您不知道他们是否会接受您的 PR。我也不知道。
这里有一个提示：团队中的某个人在这个话题中做出了回应，他们没有说“是的，我们会尽快采纳”。他们反而给了你“如果我们的 PR 在几个月内无法被核心接受，我们会这样做”。
看来这就是你的选择。
我不会对我的回复做太多解读。
我在基础设施部门工作，对开发团队的优先级没有发言权。对我来说，这个提交看起来 
，但更有经验的人可能会有不同的看法。
但我确实认为回答这个问题对于自托管者来说会是一个非常有用的建议/常见问题解答。
在我看来，插件在这里太笨重了。
2 个赞
好吧，看来我什么都不知道。
而且我一直忘记现在的员工队伍有多庞大，团队的划分一定有多细致。感觉好像昨天大家还对大部分事情了如指掌（当然，即使那时人们也有自己的专长），但那个“昨天”已经是八年前了。
5 个赞
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.