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

Cher: ...

2022-12-23T23:36:42Z

...

Cher: ...

2022-12-23T20:19:35Z

...

Cher: ...

2022-12-23T09:48:44Z

...

Cher: ...

2022-12-23T08:08:20Z

...

Cher: ...

2022-12-23T07:56:17Z

...

Cher: ...

2022-12-23T07:40:40Z

...

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

2022-12-13T08:51:12Z

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

New page

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

← Older revision		Revision as of 23:36, 23 December 2022
Line 17:		Line 17:

	[[Настройка интеграции с gitlab для пользователя]]		[[Настройка интеграции с 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.
		+
		+	Результат успешной компиляции передаётся дальше на тестирование
		+	обычным образом.

← Older revision		Revision as of 20:19, 23 December 2022
Line 17:		Line 17:

	[[Настройка интеграции с gitlab для пользователя]]		[[Настройка интеграции с gitlab для пользователя]]
−
−	~~Чтобы ejudge мог склонировать исходный код из репозитория,~~
−	~~потребуется ключ ssh. Можно использовать существующий,~~
−	~~который используется для других целей, но предпочтительнее~~
−	~~сгенерировать новую пару из приветного и публичного ключа специально для~~
−	~~использования ejudge. Такой ключ называется deploy key.~~
−
−	~~==== Генерация ключа ====~~
−
−	~~Сгенерировать пару ключей можно с помощью команды <code>ssh-keygen -t ed25519 -f ej_deploy</code>. Passphrase нужно оставить пустым.~~
−	~~При исполнении команды на стандартный поток вывода~~
−	~~будет примерно следующий вывод:~~
−
−	~~$ ssh-keygen -t ed25519 -f ej_deploy~~
−	~~Generating public/private ed25519 key pair.~~
−	~~Enter passphrase (empty for no passphrase):~~
−	~~Enter same passphrase again:~~
−	~~Your identification has been saved in ej_deploy~~
−	~~Your public key has been saved in ej_deploy.pub~~
−	~~The key fingerprint is:~~
−	~~SHA256:MZcQPKClDzn4AcM+S2tBiIJLgWKMciwxK1tj38nMs9k cher@fedora~~
−	~~The key's randomart image is:~~
−	~~+--[ED25519 256]--+~~
−	~~\|O*+ ooo. \|~~
−	~~\|@*=+ = o. . \|~~
−	~~\|O*= B o.o \|~~
−	~~\|o+=+ X . + \|~~
−	~~\|.. =o O S \|~~
−	~~\| + = \|~~
−	~~\| . o E \|~~
−	~~\| \|~~
−	~~\| \|~~
−	~~+----[SHA256]-----+~~
−
−	В итоге в текущем каталоге появятся файл <code>ej_deploy.pub</code> — это ппубличный ключ, и файл <code>ej_deploy</code> — это приватный ключ.
−	~~Публичный ключ нужно добавить в список deploy keys в системе github или gitlab.~~
−
−	~~==== Добавление deploy key в github ====~~
−
−	~~Для интеграции с github нужно сгенерированный публичный ключ~~
−	~~добавить в список deploy keys проекта на github.~~
−
−	~~Для добавления ключа на странице проекта перейдите~~
−	~~в раздел "Settings".~~
−
−	~~[https://ejudge.ru/download/img/github-settings.png]~~
−
−	~~В разделе "Settings" выберите раздел "Deploy keys".~~
−
−	~~[https://ejudge.ru/download/img/github-settings-dk.png]~~
−
−	~~В разделе "Deploy keys" нажмите на "Add deploy keys".~~
−
−	~~[https://ejudge.ru/download/img/github-settings-dk-add.png]~~
−
−	~~В поле "Key" скопируйте <b>публичный</b> ключ,~~
−	~~то есть содержимое файла <code>ej_deploy.pub</code>.~~
−
−	~~Нажмите кнопку "Add Key".~~

← Older revision		Revision as of 09:48, 23 December 2022
Line 13:		Line 13:

	=== Интеграция со стороны участника ===		=== Интеграция со стороны участника ===
		+
		+	[[Настройка интеграции с github для пользователя]]
		+
		+	[[Настройка интеграции с gitlab для пользователя]]

	Чтобы ejudge мог склонировать исходный код из репозитория,		Чтобы ejudge мог склонировать исходный код из репозитория,

@@ Line 51: / Line 51: @@
 ==== Добавление deploy key в github ====
 Для добавления ключа на странице проекта перейдите
@@ Line 56: / Line 59: @@
 [https://ejudge.ru/download/img/github-settings.png]

← Older revision		Revision as of 07:56, 23 December 2022
Line 55:		Line 55:
	в раздел "Settings".		в раздел "Settings".

−	[https://ejudge.ru/~~wikiimg~~/github-settings.png]	+	[https://ejudge.ru/download/img/github-settings.png]

← Older revision		Revision as of 07:40, 23 December 2022
Line 1:		Line 1:
	Навигация: [[Main Page\|Главная страница]]/[[Система ejudge]]/[[Использование]]/[[Интеграция с github/gitlab]]		Навигация: [[Main Page\|Главная страница]]/[[Система ejudge]]/[[Использование]]/[[Интеграция с github/gitlab]]
		+
		+	Поддерживается с версии [[Изменения в версии 3.10.0\|3.10.0]].
		+
		+	Система ejudge поддерживает хранение исходного кода решений
		+	участников в системах контроля версий github или gitlab.
		+	При определенных событиях в репозитории (например,
		+	при событии push) система контроля версий обращается по заранее
		+	настроенному URL (webhook), уведомляя ejudge, что можно тестировать
		+	очередную версию исходного кода.
		+	Затем ejudge выполняет загрузку исходного кода из репозитория
		+	с помощью git clone, компиляцию и тестирование этого кода.
		+
		+	=== Интеграция со стороны участника ===
		+
		+	Чтобы ejudge мог склонировать исходный код из репозитория,
		+	потребуется ключ ssh. Можно использовать существующий,
		+	который используется для других целей, но предпочтительнее
		+	сгенерировать новую пару из приветного и публичного ключа специально для
		+	использования ejudge. Такой ключ называется deploy key.
		+
		+	==== Генерация ключа ====
		+
		+	Сгенерировать пару ключей можно с помощью команды <code>ssh-keygen -t ed25519 -f ej_deploy</code>. Passphrase нужно оставить пустым.
		+	При исполнении команды на стандартный поток вывода
		+	будет примерно следующий вывод:
		+
		+	$ ssh-keygen -t ed25519 -f ej_deploy
		+	Generating public/private ed25519 key pair.
		+	Enter passphrase (empty for no passphrase):
		+	Enter same passphrase again:
		+	Your identification has been saved in ej_deploy
		+	Your public key has been saved in ej_deploy.pub
		+	The key fingerprint is:
		+	SHA256:MZcQPKClDzn4AcM+S2tBiIJLgWKMciwxK1tj38nMs9k cher@fedora
		+	The key's randomart image is:
		+	+--[ED25519 256]--+
		+	\|O*+ ooo. \|
		+	\|@*=+ = o. . \|
		+	\|O*= B o.o \|
		+	\|o+=+ X . + \|
		+	\|.. =o O S \|
		+	\| + = \|
		+	\| . o E \|
		+	\| \|
		+	\| \|
		+	+----[SHA256]-----+
		+
		+	В итоге в текущем каталоге появятся файл <code>ej_deploy.pub</code> — это ппубличный ключ, и файл <code>ej_deploy</code> — это приватный ключ.
		+	Публичный ключ нужно добавить в список deploy keys в системе github или gitlab.
		+
		+	==== Добавление deploy key в github ====
		+
		+	Для добавления ключа на странице проекта перейдите
		+	в раздел "Settings".
		+
		+	[https://ejudge.ru/wikiimg/github-settings.png]