[ППА]Работа с репозиторием и автотесты

Получение репо

Работы выполняются с использованием системы контроля версий GitHub. Для работы с системой требуется зарегистрироваться на GitHub.

После регистрации нужно присоединиться к GitHub Classroom. Это можно сделать, перейдя по ссылке репозитория. В качестве имени пользователя (student) нужно найти себя. Если этого не произошло, то нужно написать преподавателям, чтобы вас добавили в список.

Если вы не найдёте себя в списке и нажмёте дальше, то списке студентов со стороны преподавателей вы будете отображаться без имени, а работы безымянных студентов не проверяются.

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

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

Структура репо

Изначально у вас будет 1 ветка main. Вся разработка ведётся на main. Создавать другие ветки и работать на них, но к моменту отправки работы нужно не забыть положить всё на main.

На main может лежать .github, .gitignore, .gitattributes, test_data, tests.py, README.md:

  • .github, test_data, tests.py – настройка автотестов, модифицировать содержимое запрещено

  • .gitignore, .gitattributes – преднатроенные файлы для работы git, модифицировать содержимое запрещено

Запрещено модифицировать содержимое репозитория самостоятельно. Подтягивание изменений из шаблонного репозитория является исключением, т.к. там видно, что модификация сделана преподавателями.

Настройка репо

После получения репозитория его следует настроить. Это можно сделать двумя способами:

  1. Запустить скрипт init-repo.sh, который располагается в репозитории. Для корректной работы скрипта требуется установка bash, git (с настройками git config --global) и gh (с пройденной аутентификацией), а также авторизация в них. Этот скрипт:

    1. Создаёт вторую ветку с названием feedback. Ветка используется для следующего шага.

    2. Создаёт Pull Request с main на feedback. Через PR Вы получаете обратную связь от проверяющего по отправке.

    3. Файл classroom.yml корректируется для отображения Wokflow в GitHub Actions. Багфикс текущей частой ошибки GH

  2. Проделать все действия из скрипта вручную. /*но зачем, когда есть скрипт?)*/

В разделе Actions появится первый провальный запуск с названием Initial commit. Это нормально, является побочным эффектом от багфикс из пункта 1.3.

Загрузка решения

В репозиторий можно отправлять только файлы *.c, *.h, *.cpp, *.hpp и дополнительные файлы, изначально размещающиеся в репозитории, если другое не указано в условии задания. Если в репозиторий будет загружен CMakeLists.txt или Lab.sln/Lab.vcxproj, то это не запрещается, но при сборке на тестовом стенде у проверяющего никак использоваться и учитываться не будет.

Категорически не допускается загрузке в репозиторий не имеющих отношения к работе файлов, а также скомпилированных программ, промежуточных файлов и файлов, создаваемых средами разработки, например:

  • */Debug, */Release и прочее от Visual Studio.

  • .idea и прочее от CLion.

Автотесты

Тестирование локально на время ППА

Как и во время семестра: через запуск скрипта в репозитории, подробнеее: Автотесты (локально)

Тестирование через GitHub Actions на время ППА

В рамках ППА переделана тестирующая система. Теперь:

  • все логи отображаются внутри запуска (ваша любимая тёмная консолька).

  • число конфигураций, на которых проводится тестирование увеличено в разы.

  • все тесты стали обязательными.

  • число запусков автотестов на GutHub пока что не ограничено.

Для запуска автотестов нужно:

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

  2. Перейти в раздел Actions.

  3. Там выбрать единственный workflow (может называться по-разному в разных работах), после чего в меню запуска Run workflow.

Запуск состоит из 3 блоков: clang-format, ubuntu и windows. Прохождение каждого блокируется предыдущими.

clang-format

В первом блоке проверяется соответствие приложенному clang-format файлу.

В случае несоответствия формату в Summary будет отображатсья в каких файлах обнаружено несоответсвие:

Подробный лог clang-format в логах запуска:

ubuntu

Сборка и запуск с санитайзерами в разных конфигурациях под несколькими компиляторами. Общая структура:

Параметры сборки можно посмотреть в разделе Build:

Набор тестов одинаков для всех запусков. Результат тестирования можно посмотреть в соответсвующем разделе логов.

windows

Аналогично предыдущему блоку, только с меньшим числом конфигураций и без санитайзеров.

Подтягивание изменений из шаблонного репозитория

Тесты могут дополняться/исправляться в процессе выполнения работы, поэтому для актуализации репозитория необходимо подтянуть изменения из шаблонного репозитория самостоятельно. Подробнее: https://docs.github.com/ru/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork. Данный материал обязателен к изучению!

В исключительных случаях возможна автоматическая разливка.

PreviousЗащита работNextАвтотесты (локально)

Last updated