repo.php — скрипт обновления/установки, созданный нами и применяемый в Mediawiki4Intranet.

Contents

Возможности repo.php

Системные требования

Как работать с repo.php

Установка сборки

Обновление сборки

Коммит модуля

Добавление модуля

Удаление модуля

Создание своей сборки на основе нашей

; включаем нашу сборку
[_params]
include = mediawiki4intranet

; можно добавить свой префикс для репозиториев ($REPO будет заменено на имя репозитория)
prefix.mysrv = git:http://myserver.office.ru/git/$REPO

; добавляем или переопределяем часть расширений
[extensions/MySuperExtension]
repo = github:viewfuhrer/MySuperExtension
branch = master

; и так далее...

Далее внутри вашего нового configs запускаем команды:

php repo.php update mediawiki4fuhrer rw
git add mediawiki4fuhrer.ini mediawiki4fuhrer-index.ini
git commit -m 'Создал свою сборку'
git push

После этого вы можете работать со своей сборкой так же, как и с нашей (обновляя/добавляя/удаляя расширения). Чтобы удалить расширение, просто переопредите его параметр repo пустотой ("repo=").

Note.svg Однако, для того, чтобы наши обновления попадали к вам, вам нужно время от времени сливать наши изменения со своими. То есть, время от времени вызывать команду git pull https://github.com/mediawiki4intranet/configs.

Создание архива / экспорт всех файлов в директорию

Следующая команда создаст копию сборки в директории <directory>, без системных директорий типа .git:

Для создания архива со сборкой — просто закатайте полученную директорию в архив.

Troubleshooting

Если что-то пошло не так — с недавних пор repo.php должен вывести полный текст всех ошибок. Если этого не произошло — можно указать параметр '-j 1': php repo.php -j 1 update. Команды будут запущены последовательно и вы увидите полный вывод всех вызываемых команд.

Зачем нужен собственный скрипт?

Теоретически, вместо repo.php можно было бы просто использовать подмодули Git’а (git submodules), но у них есть определённые минусы:

  1. Когда модулей под сотню — они медленные, ибо:
    • Не умеют делать shallow клоны, всегда клонируют модули полностью.
    • Не поддерживают параллельное обновление.
  2. Сабмодули не могут работать с типичным расположением кода MediaWiki (если не клонировать репозиторий ядра), ибо:
    • Нельзя создать репозиторий, корень которого был бы submodule’ем.
    • Внутрь одного модуля нельзя поместить другой, не трогая его репозиторий.
    • Следовательно, репозиторий сборки должен являться клоном core с расширениями, подключёнными сабмодулями в extensions/ExtensionName. Изменения ядра в таком случае будут перемешиваться с изменениями модулей. Так, кстати, и делает Wikimedia Foundation в своей сборке.
      Но это неудобно, так как хочется отделить репозиторий «сборки» от кода и дать возможность легко клонировать сборки, создавать свои сборки, дополненные какими-то расширениями и т. п.
      Разве что можно было уйти от стандартного MediaWiki’овского расположения кода и поместить core в отдельную подпапку, а extensions — вне core.
  3. Есть различные неудобства и недостатки функционала:
    • В .gitmodules нельзя указать желаемые ветки модулей (например, «хочу ParserFunctions REL1_20»). Опять-таки предполагается, что за версией модуля разработчик следит сам.
    • Переключать один и тот же модуль между разными репозиториями нужно руками — например, Wikimedia → наш_Github или наш_Github → ваш_форк.
    • git archive не работает с сабмодулями — если хочется распространять архив с кодом всей сборки, нужно писать отдельный скрипт.
    • Не поддерживаются различные способы доступа к одному репозиторию, например http на чтение для всех и ssh на запись для разработчиков.
      То есть, если хочется нормально push’ить с использованием ssh-ключа, то нужно заставлять всех клонировать всё исключительно по ssh (ссылка-то прямо в репозитории прописывается).
    • Встречаются различные глюки. Например, «You are on a branch yet to be born» после неудачной попытки добавить submodule.

Часть этих проблем можно было решить с помощью хелперов или bash-скриптов, однако мы решили сразу написать цельный инструмент.

TODO