Назначение: Политика и правила. Продукт: ShariX Open · Общий компонент.
Для кого: Разработчик · Оператор развёртывания · Рецензент и приёмщик · Нейросеть.
Темы: Разработка → Передача изменений · Разработка → Проверка.
Человек, получающий исправление, должен понимать, какой файл взять, к какой версии он подходит, где выполнить команды и как определить результат. Подготовка патча заканчивается цельной поставкой:
Эта страница задаёт порядок передачи. Конкретная поставка должна содержать команды для своей базы и фактических каталогов. Установка приложения описана в отдельной процедуре.
Старую карточку и расшифровку сверяют с текущим кодом. Если нужного checkout нет, проверка похожего продукта не заменяет его. Сначала читают актуальные README, CODING_POLICY, AGENTS и инструкции Wiki относящихся к работе репозиториев.
Проверить LICENSE каждого репозитория и отметить отдельно:
Эти признаки не заменяют друг друга. Конструктор сервиса и другие отдельно лицензируемые закрытые компоненты не являются открытым ядром только потому, что установлены рядом с ним.
В публичную Wiki, открытый патч, архив исходников, граф и иллюстрацию не включают закрытый код или непубличные детали. Внутренняя поставка закрытого компонента требует разрешённого доступа и выполняется по его собственным инструкциям в intrawiki. Публичный сценарий заканчивается обозначением границы и передачей вопроса ответственным Platform.
Проверять нужно фактическое содержимое файлов, а не только названия и .gitignore. Ссылка на закрытый элемент в общем UI-каталоге также не делает его реализацию публичной. Перечень — закрытые компоненты и их границы.
Патч ShariX Open содержит пути относительно корня установки и перечисляет затронутые репозитории. В публичную поставку включается только разрешённый к открытому распространению общий код, который публикуется в своём репозитории. Для закрытого общего модуля действует отдельный внутренний порядок. После публикации shared-изменения нужно оповестить ответственного Platform для проверки, тестирования и принятия по intrawiki. Инструкция ShariX Open не включает команды, пути и собственные патчи другого продукта. Независимый компонент, например Moodle-плагин, получает отдельную поставку при соответствующем задании.
В архив вместе с патчем включают полный сценарий применения. На сценарий дают отдельную ссылку. В нём должны быть следующие сведения:
| Раздел сценария | Что указать |
|---|---|
| База и состав | Исходные commits каждого репозитория, список файлов, зависимость от предыдущих этапов и совместимость с ними. |
| Подготовка | Нужные доступы, резервные копии, состояние репозиториев и способ переноса файлов. |
| Проверка до изменения | Точные каталоги и команды проверки применимости патча к этой базе, включая затронутые вложенные репозитории. |
| Применение | Команды записи, необходимые миграции, переводы, статика и синхронизация конфигурации именно для этого изменения. |
| Публикация и передача | Какие репозитории и commits публикуются; какие сведения после публикации передать ответственному Platform, если изменён shared-модуль. |
| Запуск и приёмка | Кто выполняет действия, какая служба затрагивается, ожидаемый результат и способ его проверки. |
| Остановка и восстановление | При каких ошибках прекратить выполнение, что сохранить и как вернуться к согласованному состоянию. |
Распаковка исходников поверх работающего checkout и новый самодельный установщик не заменяют штатный порядок. Оператор переносит патчи в /tmp, поэтому в его командах указывают /tmp/ИМЯ.patch. Автор отдельно сообщает, что файлы подготовлены локально, а перенос на сервер выполняет оператор. Изображения после серверного обновления загружает агент через согласованный API; оператору не поручают установку иллюстраций или запуск клиентского CLI для неё.
В начале назвать фактический каталог и пользователя. Для ShariX Open подтверждён /opt/sharix-open-webapp-base; другой путь нужно выяснить у владельца этой установки. Имена SSH-хостов, служб, веток и БД берут из действующей конфигурации. Если значение неизвестно, указать, где его получить, а не придумывать пример как готовую команду.
Каждый следующий шаг использует результат предыдущего. Если нужно ввести параметр, объяснить его назначение и последующее использование. Все упомянутые файлы должны входить в поставку или иметь точный способ получения. Рядом с действием указывается, под кем его выполнить: deploy и root выполняют разные части процедуры.
В конце выделить три группы:
Указать наблюдаемое изменение для пользователя и ожидаемые сообщения оператора. Наличие diff или успешного импорта Python не заменяет эти сведения.
/tmp и под назначенным deploy login переходит в фактический каталог установки..rej останавливается и передаёт состояние автору поставки.repositories.sh. Если в ShariX Open используются отдельные ветки развёртывания — следует порядку update-start → update-publish → update-finish. Подробнее: передача общего кода.Для уже подготовленных исходников обычные фазы под deploy login выглядят так:
./bin/install.sh deploy --strict --use-current-checkouts --permissions=check --deps=auto --no-restart && ./bin/install.sh restart && ./venv/bin/python manage.py check && ./bin/check_acceptance.sh --with-runtime-audit
Блок выполняется из фактического корня установки. Назначение команд и параметров:
deploy — готовит зависимости, конфигурацию, схему и данные согласно установщику.–use-current-checkouts — Git не обновляется этим запуском.–no-restart — перезапуск откладывается до следующей команды.&& — последовательность прекращается при ошибке.Успех подготовки ещё не означает, что приложение запущено.
Точный сценарий указывает нужные миграции, переводы и статику и учитывает, что уже делает deploy. Новые файлы миграций не генерируют автоматически на рабочем сервере вместо подготовленной разработки.
При сообщениях Restart permissions are not installed или Runtime state needs its managed isolated directory сверяют текущую процедуру: нужный штатный root activate –strict –use-current-checkouts –permissions=check подготавливает каталоги и разрешения. Затем выполняется новый deploy login и повтор только restart. Полная установка, рекурсивное исправление прав, ручной chmod или создание симлинков не подставляются вместо выяснения этой причины.
HTTP-диагностика после restart рекомендательная. Таймаут, сетевой отказ или HTTP-код сохраняются как WARNING и исследуются отдельно от результата перезапуска. Ошибки состояния службы, прав и проверки исходников блокируют продолжение. Имя systemd unit берут из конфигурации этой установки, а не из hostname.
При ошибке патча, конфликте исходников или незавершённой миграции не переходят к следующей фазе. Сначала фиксируют выполненные шаги и состояние. Обратное применение патча проверяют заново; восстановление БД может потребовать резервной копии и отдельного плана. reset –hard, удаление файлов и повтор записи с неизвестным результатом не являются универсальным восстановлением.
Уточнить README нужного модуля, его описание в Wiki и контекстную справку изменённой страницы по роли пользователя. Учебные объяснения и примеры кода относятся к Moodle. Перед публикацией перечитать текущую страницу, сохранить правки других авторов, выполнить preview и сравнить сохранённый текст повторным чтением.
Обновления Wiki обычно сопровождаются одним обзором этапа со ссылками. Если владелец просит выполнить редактуру без уведомлений, это указание применяется к этому проходу. Общие правила подтверждения результата — приёмка изменений.
Проверены опубликованные исходники указанных ревизий. Это source-анализ; он не подтверждает применённую версию, конфигурацию или успешный сценарий конкретного сервера.
В bin/repositories.sh функция require_open_update_mode разрешает update-* только ShariX Open. Эти команды относятся к процедуре ShariX Open.
По поручению владельца от 01.11.2026 новое согласованное требование, меняющее продуктовый контракт, права, границы модулей, workflow или применимость проверок, сразу заносится в соответствующую предметную Wiki в рамках того же задания. Правило не должно оставаться только в переписке до следующего прохода.
В том же изменении устранить противоречия затронутых AGENTS.md, CODING_POLICY и README. Более позднее явное уточнение владельца имеет приоритет перед устаревшим локальным текстом. Учебные объяснения остаются в Moodle; предметные правила использования и разработки — в Wiki.
Отдельно обозначать согласованный контракт, подготовленное изменение исходников и проверенный результат установки. Перед записью перечитать текущую страницу и сохранить чужие изменения; после preview/publish выполнить GET/hash-сверку и предусмотренное уведомление со списком страниц и ссылками. Запись правила в Wiki не является разрешением на deploy и не подтверждает серверную приёмку.