Difference between revisions of "Интеграция с github/gitlab"
(...) |
(...) |
||
| (3 intermediate revisions by the same user not shown) | |||
| Line 14: | Line 14: | ||
=== Интеграция со стороны участника === | === Интеграция со стороны участника === | ||
| − | + | [[Настройка интеграции с github для пользователя]] | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | [[Настройка интеграции с gitlab для пользователя]] | |
| − | + | === Настройка интеграции в турнире администратором === | |
| − | |||
| − | |||
| − | + | Чтобы включить режим интеграции с системами контроля версий | |
| − | + | для некоторой задачи нужно установить | |
| − | + | положительное значение конфигурационной переменной задачи | |
| − | + | <tt>[[serve.cfg:problem:enable_vcs|enable_vcs]]</tt>. Например, | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | [problem] | |
| − | + | # ... | |
| + | enable_vcs | ||
| − | === | + | === Сборка и выполнение посылок === |
| − | + | Обработка посылки со стороны ejudge активируется, когда | |
| − | + | система контроля версий github или gitlab вызывает webhook, | |
| + | информирующий ejudge о пуше в репозиторий. В webhook URL | ||
| + | закодирован номер турнира, идентификатор пользователя, | ||
| + | задачи и языка программирования. Клонированием репозитория | ||
| + | из системы контроля версий и предварительной подготовкой | ||
| + | посылки занимается компонент [[ej-jobs]]. Подготовленная | ||
| + | посылка отправляется на компиляцию и тестирование в | ||
| + | главный компонент [[ej-contests]]. | ||
| − | [ | + | Сборка и выполнение посылок из системы контроля версий |
| + | состоит из следующих шагов. | ||
| + | |||
| + | ==== Клонирование репозитория ==== | ||
| + | |||
| + | Клонирование репозитория выполняется компонентом [[ej-jobs]]. | ||
| + | Клонирование выполняется командой | ||
| + | git clone GIT_SSH_URL | ||
| + | где <code>GIT_SSH_URL</code> — это адрес репозитория, | ||
| + | указанный в поле "Git SSH URL" формы настройки интеграции, | ||
| + | которая заполняется участником турнира для задачи. | ||
| + | |||
| + | Для клонирования используется приватный ключ, который был | ||
| + | скопирован в поле "SSH private key" формы настройки интеграции. | ||
| + | Ключ должен соответствовать публичному ключу, добавленному | ||
| + | в список Deploy Keys репозитория. | ||
| + | |||
| + | Клонирование выполняется во временный каталог. После завершения | ||
| + | операции отправки посылки (успешного или неуспешного) | ||
| + | временный каталог полностью очищается. | ||
| + | Если клонирование завершилось с ошибкой, то есть команда <code>git clone</code> | ||
| + | вернула ненулевой код завершения, сборка проекта завершается неуспешно. | ||
| + | |||
| + | Далее, если поле "Repo subdirectory" в форме настройки интеграции | ||
| + | имеет непустое значение, то указанный подкаталог репозитория | ||
| + | переносится в тот же временный каталог, в который выполнялось клонирование, | ||
| + | и переименовывается в <code>source</code>. Если поле "Repo subdirectory" | ||
| + | пусто, то корневой каталог склонированного репозитория | ||
| + | переименовывается в <code>source</code> и из него удаляется | ||
| + | подкаталог <code>.git</code>. В любом случае для дальнейшей | ||
| + | обработки используется каталог <code>source</code>. | ||
| + | |||
| + | ==== Запуск скрипта постобработки ==== | ||
| + | |||
| + | После клонирования проекта и подготовки каталога <code>source</code> | ||
| + | запускается скрипт постобработки. Имя скрипта задается | ||
| + | в конфигурационной переменной задачи | ||
| + | <tt>[[serve.cfg:problem:post_pull_cmd|post_pull_cmd]]</tt>. | ||
| + | Если указан относительный путь, он отсчитывается относительно | ||
| + | каталога задачи. | ||
| + | |||
| + | Скрипту постобработки передаются два аргумента командной строки: полный | ||
| + | путь к каталогу задачи и язык программирования, который был задан | ||
| + | участником в форме настройки интеграции. Скрипт запускается | ||
| + | из каталога <code>source</code> (то есть текущий рабочий каталог | ||
| + | у скрипта будет <code>source</code>). | ||
| + | |||
| + | Скрипт постобработки может модифицировать содержимое каталога, | ||
| + | например, удалив из него какие-то файлы, или наоборот, | ||
| + | скопировав в него какие-то файлы (например, скрипт сборки). | ||
| + | Скрипт должен завершиться с кодом 0, а в противном случае | ||
| + | сборка проекта завершается с ошибкой. | ||
| + | |||
| + | ==== Посылка на проверку ==== | ||
| + | |||
| + | Далее каталог <code>source</code> архивируется командой | ||
| + | |||
| + | tar cfj source.tbz source | ||
| + | |||
| + | архив прогоняется через base64, к нему впереди приписывается | ||
| + | заголовок, содержащий информацию о коммите, полученную | ||
| + | с помощью команды | ||
| + | |||
| + | git log -1 --stat | ||
| + | |||
| + | Полученный текстовый файл отправляется на проверку в ejudge | ||
| + | в указанный контест под указанным пользователем и задачей. | ||
| + | Такие посылки помечаются флагом <pre>is_vcs</pre> в базе данных, | ||
| + | чтобы они различались от обычных посылок, и чтобы их при необходимости | ||
| + | можно было корректно перетестировать. | ||
| + | |||
| + | ==== Компиляция ==== | ||
| + | |||
| + | Посылки с флагом <code>is_vcs</code> обрабатываются | ||
| + | компонентом компиляции [[ej-compile]] по-особенному. | ||
| + | |||
| + | Из текста посылки извлекается бинарный файл архива, | ||
| + | который разархивируется, и в результате воссоздаётся | ||
| + | каталог <code>source</code>. | ||
| + | |||
| + | В каталоге <code>source</code> запускается скрипт | ||
| + | сборки. Скрипт сборки задаётся с помощью | ||
| + | конфигурационной переменной задачи | ||
| + | <tt>[[serve.cfg:problem:vcs_compile_cmd|vcs_compile_cmd]]</tt>. | ||
| + | Если эта переменная не задана, используется команда <code>./build</code>, | ||
| + | то есть в каталоге <code>source</code> делается попытка | ||
| + | запустить программу <code>build</code>. Например, | ||
| + | эта программа могла быть скопирована в каталог <code>source</code> | ||
| + | скриптом постобработки. | ||
| + | |||
| + | Скрипту сборки передаются следующие аргументы командной строки: | ||
| + | * язык программирования текущей посылки | ||
| + | * рабочий каталог компиляции | ||
| + | * имя выходного файла. выходной файл должен быть создан в рабочем | ||
| + | каталоге компиляции. | ||
| + | |||
| + | Кроме того, скрипту сборки передаются все переменные окружения, | ||
| + | которые были заданы в конфигурации задачи | ||
| + | с помощью <tt>[[serve.cfg:problem:lang_compiler_env|lang_compiler_env]]</tt>. | ||
| + | |||
| + | Скрипт сборки должен сформировать выходной файл, имя | ||
| + | которого задано в аргументе командной строки. При успехе скрипт | ||
| + | сборки должен завершиться с кодом 0. | ||
| + | |||
| + | Результат успешной компиляции передаётся дальше на тестирование | ||
| + | обычным образом. | ||
Latest revision as of 23:36, 23 December 2022
Навигация: Главная страница/Система ejudge/Использование/Интеграция с github/gitlab
Поддерживается с версии 3.10.0.
Система ejudge поддерживает хранение исходного кода решений участников в системах контроля версий github или gitlab. При определенных событиях в репозитории (например, при событии push) система контроля версий обращается по заранее настроенному URL (webhook), уведомляя ejudge, что можно тестировать очередную версию исходного кода. Затем ejudge выполняет загрузку исходного кода из репозитория с помощью git clone, компиляцию и тестирование этого кода.
Contents
Интеграция со стороны участника
Настройка интеграции с github для пользователя
Настройка интеграции с gitlab для пользователя
Настройка интеграции в турнире администратором
Чтобы включить режим интеграции с системами контроля версий для некоторой задачи нужно установить положительное значение конфигурационной переменной задачи enable_vcs. Например,
[problem] # ... enable_vcs
Сборка и выполнение посылок
Обработка посылки со стороны ejudge активируется, когда система контроля версий github или gitlab вызывает webhook, информирующий ejudge о пуше в репозиторий. В webhook URL закодирован номер турнира, идентификатор пользователя, задачи и языка программирования. Клонированием репозитория из системы контроля версий и предварительной подготовкой посылки занимается компонент ej-jobs. Подготовленная посылка отправляется на компиляцию и тестирование в главный компонент ej-contests.
Сборка и выполнение посылок из системы контроля версий состоит из следующих шагов.
Клонирование репозитория
Клонирование репозитория выполняется компонентом ej-jobs. Клонирование выполняется командой
git clone GIT_SSH_URL
где GIT_SSH_URL — это адрес репозитория,
указанный в поле "Git SSH URL" формы настройки интеграции,
которая заполняется участником турнира для задачи.
Для клонирования используется приватный ключ, который был скопирован в поле "SSH private key" формы настройки интеграции. Ключ должен соответствовать публичному ключу, добавленному в список Deploy Keys репозитория.
Клонирование выполняется во временный каталог. После завершения
операции отправки посылки (успешного или неуспешного)
временный каталог полностью очищается.
Если клонирование завершилось с ошибкой, то есть команда git clone
вернула ненулевой код завершения, сборка проекта завершается неуспешно.
Далее, если поле "Repo subdirectory" в форме настройки интеграции
имеет непустое значение, то указанный подкаталог репозитория
переносится в тот же временный каталог, в который выполнялось клонирование,
и переименовывается в source. Если поле "Repo subdirectory"
пусто, то корневой каталог склонированного репозитория
переименовывается в source и из него удаляется
подкаталог .git. В любом случае для дальнейшей
обработки используется каталог source.
Запуск скрипта постобработки
После клонирования проекта и подготовки каталога source
запускается скрипт постобработки. Имя скрипта задается
в конфигурационной переменной задачи
post_pull_cmd.
Если указан относительный путь, он отсчитывается относительно
каталога задачи.
Скрипту постобработки передаются два аргумента командной строки: полный
путь к каталогу задачи и язык программирования, который был задан
участником в форме настройки интеграции. Скрипт запускается
из каталога source (то есть текущий рабочий каталог
у скрипта будет source).
Скрипт постобработки может модифицировать содержимое каталога, например, удалив из него какие-то файлы, или наоборот, скопировав в него какие-то файлы (например, скрипт сборки). Скрипт должен завершиться с кодом 0, а в противном случае сборка проекта завершается с ошибкой.
Посылка на проверку
Далее каталог source архивируется командой
tar cfj source.tbz source
архив прогоняется через base64, к нему впереди приписывается заголовок, содержащий информацию о коммите, полученную с помощью команды
git log -1 --stat
Полученный текстовый файл отправляется на проверку в ejudge в указанный контест под указанным пользователем и задачей.
Такие посылки помечаются флагом
is_vcs
в базе данных,
чтобы они различались от обычных посылок, и чтобы их при необходимости можно было корректно перетестировать.
Компиляция
Посылки с флагом is_vcs обрабатываются
компонентом компиляции ej-compile по-особенному.
Из текста посылки извлекается бинарный файл архива,
который разархивируется, и в результате воссоздаётся
каталог source.
В каталоге source запускается скрипт
сборки. Скрипт сборки задаётся с помощью
конфигурационной переменной задачи
vcs_compile_cmd.
Если эта переменная не задана, используется команда ./build,
то есть в каталоге source делается попытка
запустить программу build. Например,
эта программа могла быть скопирована в каталог source
скриптом постобработки.
Скрипту сборки передаются следующие аргументы командной строки:
- язык программирования текущей посылки
- рабочий каталог компиляции
- имя выходного файла. выходной файл должен быть создан в рабочем
каталоге компиляции.
Кроме того, скрипту сборки передаются все переменные окружения, которые были заданы в конфигурации задачи с помощью lang_compiler_env.
Скрипт сборки должен сформировать выходной файл, имя которого задано в аргументе командной строки. При успехе скрипт сборки должен завершиться с кодом 0.
Результат успешной компиляции передаётся дальше на тестирование обычным образом.
