Здравствуйте,
Нам необходимо использовать эту новую функцию для электронной почты:
Поскольку она ещё не объединена (мы предполагаем, что это произойдёт когда-нибудь), какой рекомендуемый способ запуска производственного экземпляра Discourse с включённым в ревью PR?
Я предполагаю, что нам придётся избегать регулярных обновлений Discourse, но это, вероятно, слишком упрощённый подход.
Будем признательны за любые рекомендации о том, как другие работают в такой ситуации.
Сначала: я не знаю.
Но, думаю, это может сработать:
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
и это вернёт образ, который вы собирали последним.
Это очень полезно, спасибо. В идеале мы бы хотели подождать, пока это будет слито, но так как мы новички в этом, неясно, займет ли это несколько дней, недель или месяцев.
Еще раз спасибо.
Без критики этого PR (я не изучал его подробно), но в целом я не считаю это хорошей практикой.
Используйте возможности ревью разработчиков CDCK и подождите, пока его не рассмотрят и не сольют?
Это хороший совет.
С тем, что я предложил, вы сможете увидеть, что это действительно работает (или, возможно, в спецификациях есть ответ на этот вопрос), или просто продержаться какое-то время до принятия. Многие люди всё равно ждут недели (или даже месяцы) перед обновлением.
@merefield спасибо — я полагаю, вы предлагаете просто подождать, пока это не будет слито, верно?
Мы согласны, это отличная идея. Однако в то же время нам необходимо обрабатывать отскоки писем.
Опять же, мы не знаем, сколько времени займет этот процесс, поэтому без этой информации мы будем исходить из того, что он потребует значительного времени.
Возможно, я упускаю какой-то нюанс…
Я думаю, вам безопасно попробовать это в течение нескольких недель. Если выйдет новый релиз, вы сможете решить, обновлять ли ваш PR для работы с ним или найти другое решение. Вероятно, самый простой вариант — реализовать это в виде плагина?
Погодите. А почему бы просто не сделать это в плагине?
Это стандартный подход: реализовать в плагине, а затем спросить, интересен ли вам PR. Сейчас, похоже, вы единственный на планете, кому это нужно. Добавление в ядро означает, что кто-то будет поддерживать это бесконечно; это не тривиальная задача.
Да, я не понимаю, почему это не реализовано в виде плагина.
Тогда вы могли бы просто развивать плагин отдельно от основной установки.
Как только (если) PR будет принят, вы сможете удалить плагин!
Нам также необходимо решить эту проблему для непубличных исправлений безопасности.
В наших внутренних инструментах есть код, который объединяет ветку из репозитория — я рекомендую вам использовать тот же подход.
Вот что-то подобное, что должно сработать для вас в блоке exec (вероятно, в хуке after_code):
# fetch and merge the patch
git merge REFERENCE --no-commit
bundle install # если необходимо
pnpm install --frozen-lockfile # если необходимо
@merefield @pfaffman это не просто плагин, потому что для нас это не тривиальная задача. Мы никогда не писали плагины. Если у кого-то есть инструкции, как это подключить, мы с радостью рассмотрим их!
Кроме того, я бы, вероятно, не сказал, что мы единственные, кто «хочет» netcore — это один из крупнейших ESP… на Земле, и во много раз больше некоторых других, поддерживаемых в core. Я не утверждаю, что он лучше, или что пользователи могут предпочесть другие, но netcore — это очень крупный и уважаемый ESP. На самом деле, вы можете увидеть много обсуждений об этом здесь, так как он ранее назывался pepipost:
Я считаю, что была бы уместна двойная стратегия:
Неспособность создать плагин — не самая веская причина для PR.
Третьи стороны всё ещё смогут использовать ваш плагин.
@merefield извините, почему вы считаете, что сборка плагина связана с созданием PR? Сам Netcore написал этот PR.
Возможно, я упустил какую-то деталь в том, что вы говорите.
Просто предложение. Это даёт вам дополнительную гибкость в сроках развёртывания. Кто не любит меньше зависимостей?
Потому что вы можете создать плагин.
Вы не знаете, примут ли они когда-нибудь ваш PR. И я тоже не знаю.
Вот подсказка: кто-то из команды отреагировал в этой теме, но не сказал: «Да, мы внедряем это как можно скорее». Вместо этого они предложили: «Вот что мы делаем, если у нас есть PR, который не будет принят в основную ветку в течение месяцев».
Похоже, что это ваши варианты выбора.
Не стоит слишком многого вкладывать в мой ответ.
Я работаю в инфраструктурном отделе и не имею представления о приоритетах команд разработки. Для меня коммит выглядит 
, но более опытный взгляд может иметь иное мнение.
Однако я считаю, что ответ на этот вопрос был бы полезным советом / FAQ для тех, кто разворачивает систему самостоятельно.
На мой взгляд, плагин здесь был бы излишне громоздким.
Что ж, это показывает, насколько мало я знаю.
И я постоянно забываю, насколько сейчас велик штат сотрудников и насколько разделены команды. Кажется, ещё вчера все знали почти всё (хотя даже тогда у каждого была своя специализация), но этот «вчера» был восемь лет назад.