Итак, речь не идёт о развёртывании экземпляра с базой данных и прочим.
Существует ли какой-то паттерн для управления экземпляром с использованием декларативного формата? Категории, теги, политики и т. д. Думал, что техническим пользователям было бы удобно предлагать изменения через pull-запросы, а не через темы и ручное выполнение, но не нашёл ни плагина, ни другого инструмента «как код», сфокусированного на организационной конфигурации Discourse.
Я думаю, что ожидается, что сайты будут использовать предварительно созданную категорию #site-feedback для этих целей. Её описание: «Обсуждение этого сайта, его структуры, принципов работы и способов его улучшения».
Это интересная идея. В чём её преимущество перед тем, чтобы пользователи предлагали изменения в обычных темах? Цель — создать способ отслеживания изменений конфигурации сайта с течением времени?
Настройки сайта, категории, теги, политики и т. д. можно настроить с помощью API Discourse. Возможно, создать скрипт, который будет управлять конфигурацией вашего сайта через API в репозитории Git. Скрипт можно запускать при принятии PR в репозитории. С моей точки зрения, это будет сложнее, чем вручную вносить изменения в конфигурацию сайта через интерфейс.
Принято по категории. Пока я немного полагался на существующий паттерн, собирая мнения сообщества. Для меня важно обеспечить вовлечённость сообщества в стиле GitOps, поэтому я остановился на этом варианте, но при необходимости могу переключиться на другой, если это поможет.
И да, мы действительно используем подход «конфигурация как код» для многих задач, что обеспечивает чистый контроль версий, детерминированное откатывание, прозрачный обзор изменений и так далее. Изменения через графический интерфейс не плохи (и именно так мы действуем сегодня, опираясь на обратную связь от сообщества), но это ручная операция, и контекст принятия решений может со временем утратиться. Кроме того, организационные структуры находятся посередине между инфраструктурой и самим диалогом, поэтому речь не идёт о развёртывании или восстановлении данных.
И да, триггеры на основе Pull Request (или даже Issue) могут запускать runbook, который анализирует предлагаемое изменение и выполняет операцию. Анализ различий и линтинг могут быть сложными, поэтому я интересовался, пробовал ли кто-то это уже. Этот запрос определённо относится к категории «желательно, но не обязательно» и может найти отклик лишь у определённой аудитории.
Я (и я вполне уверен, что сообщество разработчиков языков программирования тоже) был бы безумно рад такой возможности. В частности, мне бы очень хотелось иметь возможность управлять темами, компонентами и текстами сайта в репозитории GitHub, где участники могли бы легко отправлять pull request’ы. Также было бы здорово иметь возможность настраивать общие параметры сайта, но именно эти три элемента сложнее всего поддерживать через веб-интерфейс.
Если сегодня это невозможно — а я думаю, что это так, по крайней мере для платных/хостинговых экземпляров — можно ли переклассифицировать это как запрос на новую функцию? В частности, было бы замечательно, если бы темы и компоненты могли просто указывать на git-репозиторий.
Или, альтернативно, кто-нибудь уже реализовал интеграции с триггерами GitHub, предложенные выше?
Сразу после написания этого я решил перепроверить интерфейс. Похоже, это возможно — по крайней мере, для создания/импорта темы из репозитория Git! Как это работает для обновлений? Может ли система подтягивать новые коммиты? Я нашел статью Installing a theme from a private Git repository, но в ней не обсуждается обновление.
Возможно ли преобразовать существующую тему или компонент для отслеживания репозитория Git?
Вы можете экспортировать тему, загрузить её в репозиторий и установить оттуда.
У всех удалённых тем в верхней части есть раздел, где можно решить, нужно ли им автоматически обновляться при обновлении Discourse. Кроме того, существует фоновая задача, проверяющая наличие более новой версии, а также можно вручную проверять наличие обновлений. Когда становится доступна новая версия, кнопка предлагает обновить компонент.
Эту информацию также можно найти в руководстве по адресу Installing a theme or theme component.
Если вы ещё не нашли, то существует также учебное пособие по разработке тем.
Отлично, спасибо @Moin! Это охватывает два основных источника кастомизации нашего сайта.
Мне всё ещё очень хотелось бы использовать git для управления текстами сайта, так как многие из них (например, правила, FAQ и тому подобное) объёмные, сложные, и их можно сделать открытыми для вклада и проверки сообществом.
Другие настройки сайта тоже были бы полезны, но определённо не так критичны.
Обычно они создаются на основе темы в категории «Персонал». Думаю, вы можете переместить их в другую категорию и сделать пост вики-страницей. Тогда ваши участники смогут их редактировать.
Вы также можете использовать настройки сайта FAQ URL, Privacy policy URL и ToS URL и разместить эти страницы где-либо ещё.
Да, но настройка FAQ URL, к сожалению, имеет другие особенности, которые делают её использование для этой цели крайне неэффективным.
Хочу отметить, что уже сейчас очевидно: управление контентом в системе контроля версий возможно. Посмотрите на эту тему, она поддерживается на GitHub:
внизу:
хотя я не уверен, что эта функция уже выпущена или анонсирована (или, возможно, это не предполагалось).
Я начал экспериментировать с GitHub Action, который отправляет обновления в раздел site_texts панели администратора через API. Пока это довольно примитивно (и по какой-то причине падает с ошибкой 422 для больших значений), но выглядит многообещающе.
Определённо требует доработки.
В данный момент у нас нет планов выпускать его в качестве инструмента для повторного использования. Однако вы можете изучить код нашей синхронизации здесь. Он опирается на все стандартные REST-API Discourse, включая запрос из Data Explorer (подробности здесь).
