Ха-ха, как я уже говорил, я использую его для чего-то другого, я не могу просто отключить его. Surely, это не должно быть так сложно изменить порт (знаменитые последние слова, кажется)
Предлагаю задать этот вопрос в связанной теме. При беглом взгляде на этот скрипт он кажется прописанным жестко, но я могу ошибаться — возможно, скрипт скомпилирован.
Я тоже заметил жёстко прописанные значения, но есть также ссылки на конфигурацию порта в YAML-файлах и переменных окружения. Пока я сдаюсь. На то, что я хотел протестировать, уже потрачено слишком много времени.
Развернул виртуальную машину со свежим Ubuntu 22.04. Установка для разработки завершается ошибкой: Install Discourse for development using Docker - #213 by nordize
Не мой день… Но это точно не заняло несколько минут (без каламбура). Спасибо за ваше время и извините, что вы тоже его потратили впустую.
@merefield короткий вопрос: есть ли более быстрый способ обновить код плагина в контейнере, чем выполнение d/shutdown_dev; d/boot_dev, которое занимает вечность и скачивает тонну данных, так как подтягивает образы Docker? Делать это каждый раз при изменении строки кода для тестирования в браузере кажется совершенно избыточным даже для dockerized окружения.
Перезапуск сервера Rails с помощью d/rails s не видит изменений в коде плагина.
Это должно быть необходимо только в том случае, если вы удаляете или добавляете плагин, а не если вы меняете одну строку кода.
Если эта строка на Ruby или CSS, новый код будет подгружен «на лету». Если это Ruby, вы, по памяти, должны увидеть перезапуск единорогов в терминале.
Если это JavaScript, вам просто нужно обновить браузер.
Я должен был упомянуть, что мой плагин находится в символической ссылке, и любые изменения не отражаются, если вы не выполните d/shutdown_dev; d/boot_dev (это также указано в руководстве), но я надеялся, что существует обходной путь через сам Docker, поскольку эти файлы должны быть просто смонтированы. Возможно, я спрошу в другой теме или попробую внести изменения как обходное решение (или откажусь от использования символических ссылок).
Мне это кажется неправильным. Процесс сервера просто перезапускается, как и при установке без Docker. Символические ссылки не должны влиять на работу, и это правильный подход. Я не понимаю, почему у вас это работает иначе…
Что ж, не стесняйтесь попробовать. Я бы не стал писать об этом, если бы перезапуска Rails и Ember было достаточно. Как я уже говорил, руководство также указывает на это.
Согласно руководству, выполнение этих команд перезапуска необходимо только при изменении набора плагинов (например, при удалении или добавлении действительной символической ссылки). В противном случае Rails должен обнаруживать изменения в коде и автоматически перезапускать свои процессы. Возможно, эту функцию можно отключить в настройках, но по умолчанию она должна быть включена.
Ниже приведен пример автоматической перезагрузки, хотя она выполнена в среде разработки без Docker, но поведение должно быть аналогичным:
[DEV]: Изменены файлы, которые не загружаются автоматически. Перезапуск сервера...
- plugins/discourse-multilingual/extensions/post.rb
ПЕРЕЗАПУСК UNICORN
I, [2022-06-15T13:25:29.082415 #227981] INFO -- : получен статус процесса #<Process::Status: pid 228047 exit 0>, worker=0
I, [2022-06-15T13:25:29.082642 #227981] INFO -- : получен статус процесса #<Process::Status: pid 228048 exit 0>, worker=1
I, [2022-06-15T13:25:29.082788 #227981] INFO -- : получен статус процесса #<Process::Status: pid 228049 exit 0>, worker=2
I, [2022-06-15T13:25:29.082877 #227981] INFO -- : мастер завершен
I, [2022-06-15T13:25:29.947587 #228661] INFO -- : обновление списка Gem
Получен сигнал TERM
Остановка
Завершение неактивных потоков
Планировщик завершает работу...
Пауза для завершения выполнения задач...
Пока!
Запуск наблюдателя изменений CSS
I, [2022-06-15T13:25:38.326511 #228661] INFO -- : прослушивание адреса=0.0.0.0:3000 fd=25
Я отредактировал файл post.rb и сохранил его, остальное выполнено автоматически.
Извините, у меня сейчас нет доступа к машине разработки на основе Docker, чтобы подтвердить, что это работает и в Docker-окружении, но я помню, что так и есть, если только что-то не изменилось.
Я не выдумываю, знаете ли 
, и мне нечем заняться, когда мне говорят, что это должно работать Я следовал этой инструкции буквально на новой установке Ubuntu 22.04 в виртуальной машине.
- Ссылка на плагин в подпапку discourse/plugins/ и изменение JS-кода в плагине не видны, если я не выполню d/shutdown_dev; d/boot_dev, несмотря на перезапуск d/rails s и d/ember-cli.
- Копирование плагина в подпапку discourse/plugins/ и изменение JS-кода в плагине видны без выполнения d/shutdown_dev; d/boot_dev, но только после перезапуска d/rails s и d/ember-cli.
Чувствуйте себя свободными попробовать вышеуказанное. Речь идет о плагине discourse-math, изменении кода в assets/initializers/javascript/*.js (помните, что эти конкретные файлы плагина подгружаются отдельно и не вызываются браузером напрямую через GET; не уверен, имеет ли это значение, я пока не копался слишком глубоко в том, как Discourse работает внутри).
p.s. Я знаю, что мне нужно обновить браузер (обходя кэш)… дайте мне немного кредита.
Прямо из первых уст, так сказать:
Так что проблема, возможно, локальна для вас или представляет собой регрессию в текущей сборке, хотя последнее кажется маловероятным.
Я сдаюсь, вы победили. Если когда-нибудь попробуете сами, дайте знать.
Я, конечно, не пытаюсь «победить», но нам необходимо достичь общего понимания:
- система должна автоматически перезапускаться при изменениях в бэкенд-коде.
d/shutdown_dev; d/boot_devдолжно быть необходимо только при изменении набора плагинов, а не отдельных строк кода.
Это должно сократить область поиска для исправления проблем.
Я только что сделал git pull и попробовал внести изменение — система перезапустилась, так что это не регрессия сборки.
Ещё более странной для меня является ситуация с Docker: в такой конфигурации случайно переопределить упакованное поведение сложнее, поэтому система должна работать надежнее.
Я проверю это на своей Docker-сборке, когда вернусь домой.
Понимаю, что в текущем виде рабочий процесс может вызывать раздражение и фрустрацию; это точно расстроило бы и меня.
Если вы полностью очистили кэш, то на данном этапе мне нечего предложить.
Обратите внимание: инициализаторы выполняются только один раз при первом открытии страницы. Поэтому перезапуск серверных процессов в данном случае не имеет смысла (и касается только бэкенд-кода).
При разработке веб-приложений я всегда запускаю инструменты разработчика с отключенным кэшем. Я новичок только в коде и инструментах Discourse, но не в веб-разработке. Я также задал вопрос в теме с руководством. На данный момент я просто скопировал директорию плагина в discourse/plugins/, чтобы избежать проблем.
Позже сегодня я попробую что-то подобное и отпишусь.
Насколько я могу судить по вызовам из браузера, JS-код из инициализатора подгружается через discourse-math.js с помощью eval() (при каждом открытии страницы). Это явно указывает на то, что какой-то серверный компонент обрабатывает и кэширует этот JS-код из инициализатора (который я изменяю), и, следовательно, именно этот серверный кэш должен быть принужден к повторному кэшированию… что не происходит, если плагин является символической ссылкой, но работает, если он скопирован.
Я не знаком (и не хотел разбираться в этом сейчас из-за нехватки времени) с инструментарием Discourse… поэтому я занимаюсь реверс-инжинирингом и задаю вопросы.
Разработка без Docker:
Я только что попробовал это в инициализаторе — перезапуск каких-либо процессов не потребовался, достаточно было просто обновить страницу в браузере, чтобы изменения в JS-коде применились. Это было в среде без Docker. Позже я попробую и там.
некоторое время спустя…
Разработка с Docker:
Теперь я зашел на свой ПК и попробовал решение с Docker, для которого сделал полную чистую установку. Я наблюдаю то же поведение: изменения в инициализаторе применяются, серверы остаются запущенными, достаточно просто сохранить файл и обновить страницу в браузере — пересборка контейнера не требуется.
Таким образом, поведение одинаковое.
(В качестве примера я использовал плагин Discourse Locations.)
Вы уверены, что с вашим инициализатором всё в порядке?
Учитывая, что после перезагрузки всё работает, да, я уверен. Для 100% надёжной воспроизводимости вы можете попробовать конкретный плагин, о котором я упоминал: включите его через графический интерфейс и выберите опцию Katex в GUI, затем отредактируйте файл JS инициализатора, который я указал, и создайте пост с кодом LaTeX внутри. Этот плагин может быть особенным — возможно, он загружает свой JS-инициализатор на лету только если пост содержит код LaTeX (именно так я бы поступил, если бы проектировал Discourse)… Но я не ожидаю, что вы потратите время на решение этой проблемы, и я не пытаюсь убедить вас, что я ничего не выдумываю
Да, хороший момент.
Это очень-очень странно.
Мое единственное предложение на данный момент — перейти на установку без Docker (к сожалению, это займет больше времени 
) и посмотреть, как это сработает?
Было бы полезно получить от команды мнение о том, что может идти не так в вашем случае. Однако решение с Docker, безусловно, должно было бы снизить вероятность разного поведения, так как оно контейнеризировано и атомарно 