У меня стандартная установка (правка: не для разработчиков) Docker в /var/discourse. Возможно ли использовать локальную директорию плагинов для загрузки в Discourse вместо ссылки на удалённый репозиторий GitHub из app.yml? Если да, то как?
Я попробовал два метода, которые, как мне казалось, должны были сработать:
Склонировал discourse-math с GitHub в /var/discourse/plugins/discourse-math. Команда launcher rebuild ничего не сказала о discourse-math, и плагина discourse-math нет ни в монтировании Docker, ни в GUI. Значит, папка plugins игнорируется?
Также пробовал склонировать в другую директорию вне /var/discourse и создать символическую ссылку на /var/discourse/plugins/discourse-math … результат тот же.
Склонировал репозиторий GitHub в /var/discourse-math.git и отредактировал свой app.yml, указав - git clone file:////var/discourse-math.git, но тогда launcher rebuild выдал ошибку fatal: '/var/discourse-math.git' does not appear to be a git repository … вроде бы лаунчер уже запускает это внутри контейнера Docker? При ручном запуске cd /tmp && git clone file:////var/discourse-math.git всё работает отлично.
Директория plugins находится вне контейнера Docker и подключена как том.
Таким образом, если вы запускаете свой Discourse в Docker из директории ~/discourse, вы можете клонировать плагины или создать символическую ссылку на ~/discourse/plugins локально.
Да, я в курсе о dev-установке, но у меня стандартная установка через Docker (то есть не dev-установка). Поэтому мой вопрос остаётся в силе: можно ли загрузить плагин из локальной директории или только удалённо через GitHub с помощью app.yml?
P.S. Я прекрасно понимаю, что «правильный» подход — это использовать dev-установку и тестировать там. Мне же нужен был быстрый и простой способ модифицировать и протестировать плагин, чтобы не проходить через всю боль настройки dev-окружения.
Понял, ваша нестандартная конфигурация меня сбила с толку.
При установке в продакшн плагины будут клонироваться в контейнер, поэтому этот вариант не подходит для локальной разработки плагинов, так как для этого процесса вам потребуется загружать изменения в GitHub.
Я предлагаю отказаться от этой конфигурации и использовать один из двух основных вариантов разработки: с Docker или без Docker.
Просто чтобы убедиться, что я правильно понял: вы имеете в виду, что он клонирует удалённые плагин из GitHub, но не может клонировать из локальной директории, даже через GitHub по протоколу file:///? Я правильно понимаю, что launcher.sh в этот момент выполняется внутри контейнера, а не на хост-машине, то есть клонирует из GitHub уже внутри контейнера, а не клонирует с хоста в подключённую папку хоста… что позволило бы мне выполнить git clone file:///…
Если вы хотите превратить установку для продакшена в «Франкенштейна», способного получать доступ к локальным смонтированным директориям, вам потребуется изменить скрипты сборки, предоставив ему такой доступ. В этом случае вы сами будете нести ответственность за поддержку этих кастомизаций.
На мой взгляд, вы просто создаёте себе лишнюю работу и повышаете хрупкость системы.
Установка через Docker для разработки создана именно для того, чтобы предложить вам решение с минимальными затратами на поддержку для эффективной локальной разработки плагинов. Пожалуйста, рассмотрите возможность использования её.
Я понимаю, и вы, конечно, правы. Это было простое изменение для тестирования в файле JavaScript плагина. Я отредактировал его напрямую в контейнере (/var/www/discourse/public/assets/plugins/discourse-math-.js), но по какой-то причине мои правки не отображаются в браузере — браузер видит старый файл, несмотря на очистку кэша. Вероятно, это связано с тем, что файлы JavaScript плагинов кэшируются встроенным nginx или чем-то подобным (?).
Буду очень благодарен за совет, как отредактировать текущий файл JS в контейнере (как бы это ни звучало нелепо) и сделать изменения видимыми для браузера.
Возможно, я уже угодил в категорию «Не нашёл времени написать короткое письмо»… У меня не было времени пройти правильный путь установки для разработки, и я не ожидал, что модификация файла JS внутри контейнера окажется такой сложной (мало времени, чтобы разобраться, как Discourse кэширует файлы JavaScript плагинов, чтобы мои изменения отображались в браузере) и так далее.
Это файл js существующего плагина (а именно инициализатор), который я хочу модифицировать. Компоненты темы не помогут (если только я вас не неправильно понял).
Компоненты темы, как я полагаю, загружаются последними, поэтому они будут переопределять плагин.
Другой хороший вариант — просто сделать форк плагина, клонировать его локально для внесения изменений и тестирования с помощью локальной установки dev (;). Как только вы будете довольны результатом, сделайте коммит и отправьте изменения в свой форк, а затем используйте форк для продакшена.
Однако решение с компонентом темы имеет преимущество: вам не нужно поддерживать форк, что может стать проблемой по мере развития основного плагина.
Не уверен, что компонент Theme поможет, когда мне нужно модифицировать файл вроде этого… Этот файл (вместе с другими), насколько я понимаю, проходит через маппер и т. д., чтобы сгенерировать файл контейнера /var/www/discourse/public/applets/plugins/discourse-math-.js, который загружает браузер. Мне нужно изменить только последний, но браузер всё ещё видит старый файл, как будто есть кэширование на стороне сервера.
Локальная установка для разработки отнимает много времени и сил, но, возможно, придётся прибегнуть к ней, если ничего не сработает. Я не ожидал, что грязная модификация JS-файла плагина окажется настолько болезненной. Также до сих пор не понимаю, почему мои прямые правки не отображаются в браузере, если только в nginx контейнера нет кэширования на стороне сервера (не знаю почему, учитывая, что это JS).
В любом случае, время, которое я мог уделить этому сегодня, истекло :(. Спасибо за помощь в любом случае!
Не буду вдаваться в подробности того, чего именно вы пытаетесь достичь, но чтобы гарантировать выполнение одного инициализатора после другого, используйте параметр after:. Пример:
Инструменты для разработки развивались именно для таких целей, поэтому, если есть возможность, используйте их. Настройка среды разработки Docker займёт минуты, а не часы, и делать это нужно только один раз. После этого она пригодится для множества задач. Не соблазняйтесь установкой в режиме production локально только потому, что вы с ней знакомы! Она просто не предназначена для таких целей.
Скажите, что я глуп, но как изменить порт по умолчанию 3000 на другой? d/boot-dev --init не работает, так как я использую этот порт для чего-то другого. Я попробовал -e UNICORN_PORT=4200. В руководствах, которые я видел, ничего не сказано о порте. Файл thin.yml в config/cloud/cloud66/files, похоже, тоже игнорируется.
3000 — это порт сервера Ruby, а 4200 — порт Ember. Оба процесса должны быть запущены. Доступ к сайту в браузере осуществляется через порт 4200. Может, обсудить установку dev-docker в теме про dev-docker?
Что ж, d/boot_dev --init не работает (ошибка запуска прокси пользовательского пространства: listen tcp 127.0.0.1:3000: bind: адрес уже используется). Возможно, я займусь этим позже. Спасибо за ваше время. Жаль, что такие вещи не описаны лучше.
Она просто не предназначена для таких целей.