Непрерывная интеграция для ученических заданий

Хорошо, так что это может показаться немного странным, но вот оно.

Я изучаю лабораторию структур данных и алгоритмов в своем местном университете и хочу, чтобы мои ученики были в курсе всех интересных и интересных событий. До сих пор я использовал простой репозиторий git, который каждый ученик разветвлял, и всякий раз, когда они выполняли задание, они делали запрос push + pull, я бы просмотрел их код, и если все будет в порядке, я бы объединил запрос pull основное репо. Это работает очень хорошо, но я хочу сделать что-то более интересное.

Лаборатория учится на C (даже С++) (и нет, я не хочу вступать в какую-либо полемику о том, почему лучше будет использовать другой язык). Я хочу сделать что-то вроде выполнения сборки Jenkins при каждом нажатии ученика, который проверяет некоторые предопределенные тесты для этой задачи.

Например, на вторую неделю я дам им домашнее задание со списками. Я хотел бы сам написать тесты для этой домашней работы, а затем автоматически проверить, что они сделали с помощью этих тестов.

Что у меня есть:

24/7 работает машина CentOS, которую я могу использовать, чтобы что-то добавить (у меня есть Jenkins и Tomcat, работающие на нем atm)
достаточно времени и силы воли, чтобы попытаться сделать свой опыт в этой лаборатории хорошо стоящим.

++ очень приятное дополнение для всего этого было бы использовать что-то вроде сонара в качестве верификатора кода. И проверять дублированный код внутри своих ветвей (чтобы увидеть, кто-нибудь скопировал ответ от кого-то другого)

Я на правильном пути, идя на сервер Jenkins, думая о гидролокаторе и т.д.? Я в отъезде? Я не думаю, что это невозможно. Это может быть сложно, да, но это делает его забавным ^^

"поток", который я хочу, это:

каждый студент является частью организации git + repo
они создают ветку от локального мастера (я наложу ограничение, например: "используйте только подпапку с вашим именем" )
главная ветвь будет содержать тесты
они будут работать над своей домашней работой на своей ветке, а затем подтолкнуть ее к Jenkins/Gerrit/whatever
ветвь каким-то образом будет протестирована, и если все тесты пройдут, она будет объединена с мастером.

От имени моих дорогих учеников, спасибо.

Ответ 1

TL; DR: да, что вы хотите сделать это выполнимо, и вы уже смотрите на правильные инструменты.

То, что вы хотите, кажется вполне выполнимым: установите Git плагин для Jenkins, настройте его для отслеживания каждой ветки репо и он уже может запускать сборку после каждого нажатия.

Поскольку вы можете выполнять произвольные скрипты во время сборки Jenkins, вы можете предоставить разрешения на нажатия для пользователя Jenkins и слить его и нажать код, если все тесты пройдут.

Затем вы также можете установить сервер сонара и вызвать его через плагин Sonar, и ваши ученики получат дополнительную информацию.

С другой стороны, Геррит может быть немного переполнен тем, что вы ищете. Вернее: это ценный инструмент, но я считаю, что он не нужен для первой итерации.

Я могу думать о двух типах трудностей:

Сценарии/Угловые случаи
Если вы хотите, чтобы ученик не играл в систему,

Для (1), я имею в виду, что вам нужно будет реализовать свои правила (например, "только создайте подпапку, принадлежащую последнему коммитору"; "не создавайте комманды слияния на master";...), И вы, вероятно, столкнетесь с такими проблемами, которые:

Вы не хотите, чтобы новый Jenkins запускался при компиляции, только что нажатой заданием Jenkins, поэтому вам придется принять это во внимание в вашей сборке script
Что делать, если вы хотите одновременно запустить несколько Jenkins, и два запуска пытаются объединить и одновременно нажать

Думаю, вам просто нужно исправить эти сбои, как вы их обнаружите. Подумайте о создании резервных копий вашей конфигурации Jenkins (вы также можете сохранить их в ad hoc git repo).

Для (2), я имею в виду, что вы можете учесть, например, случай, когда студент удалял из репо те тесты, которые его реализация не может пройти. Или случай студента, который будет напрямую нажимать на мастера.

Я считаю, что вы могли бы добавить много проверок для предотвращения такого рода обмана, но вместо того, чтобы вступать в "технологический конфликт", я думаю, было бы более здоровым просто сказать им, что вы им доверяете.