Хорошо, допустим, у меня уже есть хорошо проработанный плагин в режиме разработки. Как мне перенести этот плагин в продакшен, не полагаясь на сторонние сервисы? Существует ли вообще такой способ?
Да, это объяснено в этом документе
Вы серьёзно? Весь этот учебник опирается на GitHub, а мой вопрос касается того, как не зависеть от сторонних сервисов.
Разместите его на GitHub или GitLab, клонируйте как обычно.
Сам Discourse зависит от довольно большого количества внешних сервисов, таких как Github, Docker Hub, Rubygems, реестр NPM и LetsEncrypt. Просто сделать развёртывание вашего плагина независимым от Github, на мой взгляд, не имеет особого смысла.
О, ты прав, я упустил эту часть. 
Это имеет смысл, потому что я разработал множество небольших плагинов, которые выполняют простые задачи и поэтому не требуют обновлений. Управление GitHub для размещения таких мелких плагинов — это излишество, слишком много работы.
Выложить плагин на GitHub — дело менее чем одной минуты. Создаёте репозиторий и копируете/вставляете shell-скрипт, который он выдаёт после создания, а он уже сам выполнит git init, git add и git push. Вот почему вы — первый, кто задал этот вопрос. Также стоит держать свои плагины под контролем версий, независимо от того, насколько они малы.
Можно скопировать скрипт установки и модифицировать его так, чтобы он напрямую копировал каталоги ваших плагинов в образ Docker. Это предполагает, что код плагина у вас уже есть локально. Однако я подозреваю, что поддерживать модифицированный скрипт установки в актуальном состоянии с учётом обновлений — это в 10 раз больше работы.
Я не первый, кто задаёт этот вопрос (другие уже спрашивали), но обсуждение всё больше усложняется, и в итоге вы так ничего и не отвечаете.
Нет никаких обоснований для такого подхода, который не допускает гибкости. Попробуйте хотя бы раз WordPress или другой сервис, и вы увидите, что установка плагинов не является кошмаром, как это бывает в Discourse.
Использование GitHub — это нормально, но разве стремление работать локально осуждается?
Чтобы было ясно: я не работаю на Discourse.org. Я просто пользователь здесь, как и вы.
В Communiteq мы разработали собственную панель управления, которая позволяет легко устанавливать и удалять плагины. Интересный факт: она не заменяет GitHub, а построена на его основе.
Если бы вы когда-нибудь создавали (а не просто устанавливали) плагин для WordPress, вы бы никогда так не сказали, потому что сейчас это и есть настоящий кошмар.
Использование правильной системы контроля версий сэкономит вам массу нервов и проблем в будущем. Это защитит ваш плагин на перспективу и поможет вести журнал обновлений.
Это обеспечивает модульный подход к разделению ответственности, снижая сложность.
Это позволяет независимо управлять вашими экземплярами, делая миграцию и пересборку серверов гораздо проще.
Кроме того, это профессиональный подход.
Мне интересно, как вы создавали и тестировали «хорошо проработанный» плагин, не используя GitHub или какой-либо другой аналогичный сервис репозиториев? Как вы разрабатывали «множество небольших плагинов» для Discourse?
Ведение себя в конфликтном тоне с людьми, которые пытаются вам помочь, ни к чему хорошему не приведёт. Если вы действительно разрабатывали плагины, как утверждаете, то знаете, что их установка на Discourse — не кошмар; использование репозитория и редактирование файла app.yml должно быть простым делом для кого-то, кто самостоятельно хостит свой сервер и имеет опыт разработки плагинов.
Не знаю, должно ли хостинг-решение Codeberg работать с плагинами Discourse. Если должно, то, вероятно, именно это ищет автор темы.
Я согласен с тем, что стоит подвергнуть сомнению использование GitHub. Они удалили около 300 000 репозиториев (по жалобам DMCA) без предварительного уведомления, а методология исследования CMU — проверка того, были ли ранее наблюдавшиеся репозитории впоследствии удалены, — предполагает, что через внутренние механизмы enforcement было удалено на порядок больше репозиториев.
Согласно одному лишь исследованию CMU, в ходе одной акции по “накрутке звёзд” было удалено около 14 000 репозиториев, тогда как ежегодно по DMCA удалялось от 20 000 до 47 000. Общей статистики нет, поскольку эти репозитории теперь возвращают только ошибки 404.
Я имею в виду, что для плагинов Discourse реальной угрозы нет, но теперь Farble стал вопросом национальной безопасности, и мы не знаем, что может произойти в ближайшем будущем, если каждый пользовательский пост потребуется верифицировать через Persona или нечто подобное.
Так что вы рекомендуете команде Discourse уйти с GitHub?
Есть несколько альтернатив, и это нормально. Пользуйтесь ими, если необходимо, но если вы не готовы потратить немало усилий, то, на мой взгляд, не стоит запускать Discourse.
Вы называете это агрессивностью? Извините, но никто не вёл борьбы, вы, вероятно, просто слишком чувствительны. И извините, если это прозвучало агрессивно.
В любом случае, отвечая на ваш вопрос: конечно, я сделал это с помощью одноразового аккаунта GitHub, но они настолько малы, что мне не приходится их слишком много тестировать или писать много кода.
Я уже установил их с помощью одноразового аккаунта и проверил, что они работают, но в долгосрочной перспективе я не хочу каждый раз следить за репозиторием, когда захочу внести изменения. Я не шучу, когда говорю, что они очень маленькие. Например, один из них просто добавляет кнопку на внешнюю страницу на главной странице, и всё.
Это как сказать, что ты хочешь машину, но тебе лень пройти ежегодный техосмотр.
Это просто цена, которую приходится платить за размещение на открытом веб-пространстве.
Я уверен, что если захочешь, ты сможешь найти способ модифицировать скрипты установки и создать на них символические ссылки на своём сервере, но ты, похоже, не настроен на работу, и ответственность за написание и поддержку этого решения ляжет на тебя.
Если ты сможешь ужать это до Theme Component, то можешь пойти путём Хит-Робинсона и использовать discourse_theme для отправки кода с локальной машины на сервер, но не ной, если твоя локальная машина сломается, потеряется или будет украдена, и ты не сможешь восстановить свой код (не выяснив предварительно, как получить живую копию с сервера).
Ещё проще: если вы не хотите устанавливать gem discourse_theme, темы можно загружать в виде ZIP-файла, а многое можно настроить прямо в административном интерфейсе.
И ещё раз: если вы не работаете с Ruby, плагин вам вообще не нужен, так что, скорее всего, вам нужна именно тема… и git тут не потребуется.
Отличная идея! Но преимущество discourse_theme заключается в возможности мгновенного обновления на месте, что позволяет быстро проверять изменения без необходимости архивировать обновление и загружать его заново.
Звучит скорее как желание ездить на машине, но никогда не заезжать на заправку. «Я просто зачерпну бензин руками и залью в бак». 
Если вы используете GitHub для разработки плагинов, то использовать его же как источник для установки — тривиальная задача. Отправка изменений в репозиторий требует меньше усилий, чем ручная передача обновлённых файлов плагинов на сервер.
Скорее всего, вы пытаетесь обойти процесс установки, чтобы развернуть плагины на хостинговой версии Discourse.