Автотесты на GitHub
В ваших репозиториях настроены автотесты для проверки, что в репозитории код в состоянии собраться и собранный исполняемый файл отрабатывает верно.
Почему важно запускать автотесты:
Если вы совершили какую-нибудь глупую ошибку и отправили код на проверку, то получить ответ вида "результаты работы оформлены не по шаблону" или "не всё отправлено на проверку" вы можете спустя 3-4 дня, хотя правка такой ошибки занимает от силы пару минут.
Также в случае, если у вас есть возможность запускаться только на одной системе, например, Linux, то найти ряд ошибок, которые сходу видно под Windows вы сможете либо в ответе проверяющего (что опять же долго ждать), либо сразу увидите это в логах.
Запуск всех тестов через GitHub Actions
Отправить в репозиторий файлы с исходным кодом.
Перейти в раздел Actions. Там выбрать workflow (BuildTest или CI/CD), после чего в меню запуска Run workflow проставить галочки у тестов которые вы хотите запустить (галочки для преподавателей/проверяющих проставлять не надо). У галочек добавлено описание, что они означают.
Дождаться окончания запуска. Новый запуск (run) появляется в списке запусков с некоторой задержкой (до 10 секунд), так что наберитесь терпения или press F5.
Ознакомиться с результатами запуска. Если всё прошло успешно, то в Summary запуска вы увидите что-то в таком духе (скрин ниже):
1 – запуски (job) на 1 или 2 ОС
2 – Summary по каждому запуску (job). Это отчет, который оформлен для вас в человекочитаемом виде, чтобы вы не мучались и не разбирались в логах.
В Summary отображается статус проверки и ниже приводятся логи тестов на обеих системах. Логи условно можно поделить на
Build
,Test
.Build
содержит информацию о компиляции и линковке.
Запускать автотесты можно как через web-интерфейс, так и с использванием gh API (имя .yml файла можно найти в репозитории в .github/workflow):
gh workflow run classroom.yml --ref main -f <field>=<value>
Название полей и значений будет приведено в условии каждой работы.
gh workflow run classroom.yml --ref main -f r1=true -f r2=true -f r3=true
Ход тестирования (консольный интерфейс)
Проверка статуса: gh run list --workflow=ci.yaml
Просмотр прогресса: gh run watch -i 1
Подробнее: https://cli.github.com/manual/gh_run
Ход тестирования (web-интерфейс)
Логи проверки можно посмотреть в разделе Actions для последнего запуска (самый верхний).

Build
. Если логи сборки пустые, то в Summary этого шага видно не будет. Иначе вуду выведены логи компилятора и линковщика. Например:

Если же ваш код собрался, то начинается выполнение шага Test
, в котором ваша программа проверяется на каком-то простеньком для каждого задания тесте (или нескольких тестах).
Если все тесты пройдены верно, то вы увидите следующее

Здесь указывается путь с гиперссылкой на входной, выходной файлы, код возврата, полученный от вашей программы, логи потоков вывода и вывода ошибок, а также общий статус:
PASSED
– тест пройден;FAILED
– тест не пройден, смотрим результаты и ожидаемые значения;PASSED (... not checked)
– в тесте не проверялись полученные результаты (только что они логируются куда надо и программа не упала), сверка результата с ожидаемым производится вручную.
Если же ваша программа не выполняет все функциональные требования согласно заданию и требованиям к работам, то тесты не пройдут и вы увидите сообщение об ошибке. Например, ниже представлен случай, когда программа завершилась с ненулевым кодом возврата и вывела сообщение об ошибке.

По результатам тестов вам в репозиторий с GitHub серверов будут залиты выходные файлы. Все тестовые файлы лежат в репозитории в директории test_data
.
Если тесты на Ubuntu не отработали полностью корректно, то следующих runner-ах проверка не будет запущена. Поэтому если вы видите, что проверка завершилась неуспешно и вы не понимаете почему, то вместо того, чтобы тратить попытки на GitHub, лучше сразу написать проверяющему о своей проблеме.
Запуск на удалённом сервере курса с видеокартой через GitHub Actions
В GitHub Actions добавлена опция запуска тестирования на удалённом сервере курса.

При выборе этой опции после успешной отработки на GitHub-runner (GH-серверах), генерируется запуск на self-hosted-runner (нашем сервере) и встаёт в очередь. Т.к. одновременно может быть запущен только 1 workflow, то ваш запуск встаёт в общую очередь и в худшем случае очередь может достигать 3 часов.
Если запуск стоит очень долго в очереди (более часа), то можно написать Виктории с уточнением, не упал ли сервер. Или же проверить сервер самостоятельно, попытавшись подключиться к нему под своими login+password или спросить у того, кто по таблице сейчас сидит на сервере.
Все параметры запуска вам будут выведены в SUMMARY на GitHub. Если запуск на видеокарте отработал успешно, то вы увидите информацию о генерации файлов с результатами профайлинга:
Session output path: *\./rcprof_1/rcprof_1.occupancy
Session output path: *\./rcprof_1/rcprof_1.csv
Все файлы будут загружены в репозиторий. Файлы сессии можно импортировать в CodeXL для более удобного просмотра, подробнее в разделе про работу с CodeXL.
Если генерация файлов не удалась (запуск производился на процессоре или программа упала), то логи будут выглядеть следующим образом:
Failed to generate profile result *\./rcprof_1/rcprof_1.occupancy.
Failed to generate profile result *\./rcprof_1/rcprof_1.csv.
Last updated