Автотесты на GitHub

В ваших репозиториях настроены автотесты для проверки, что в репозитории код в состоянии собраться и собранный исполняемый файл отрабатывает верно.

Почему важно запускать автотесты:

1. Если вы совершили какую-нибудь глупую ошибку и отправили код на проверку, то получить ответ вида "результаты работы оформлены не по шаблону" или "не всё отправлено на проверку" вы можете спустя 3-4 дня, хотя правка такой ошибки занимает от силы пару минут.

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

Запуск всех тестов через GitHub Actions

1. Отправить в репозиторий файлы с исходным кодом.

2. Перейти в раздел Actions. Там выбрать workflow (BuildTest или CI/CD), после чего в меню запуска Run workflow проставить галочки у тестов которые вы хотите запустить (галочки для преподавателей/проверяющих проставлять не надо). У галочек добавлено описание, что они означают.

   
3. Дождаться окончания запуска. Новый запуск (run) появляется в списке запусков с некоторой задержкой (до 10 секунд), так что наберитесь терпения или press F5.

4. Ознакомиться с результатами запуска. Если всё прошло успешно, то в Summary запуска вы увидите что-то в таком духе (скрин ниже):

   1. 1 – запуски (job) на 1 или 2 ОС

   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 для последнего запуска (самый верхний).

GitHub Actions - Failed with Logs

---

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

GitHub Actions Failed with Logs

---

Если же ваш код собрался, то начинается выполнение шага 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.