Интеграция с github/gitlab

Навигация: Главная страница/Система ejudge/Использование/Интеграция с github/gitlab

Поддерживается с версии 3.10.0.

Система ejudge поддерживает хранение исходного кода решений участников в системах контроля версий github или gitlab. При определенных событиях в репозитории (например, при событии push) система контроля версий обращается по заранее настроенному URL (webhook), уведомляя ejudge, что можно тестировать очередную версию исходного кода. Затем ejudge выполняет загрузку исходного кода из репозитория с помощью git clone, компиляцию и тестирование этого кода.

Интеграция со стороны участника

Настройка интеграции с 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.

Результат успешной компиляции передаётся дальше на тестирование обычным образом.