Репозиторий и CI

Код каждой сдачи должен находиться в Git-репозитории на GitHub или GitVerse. Проверяется не архив и не скриншот, а конкретный commit SHA, для которого встроенная система CI платформы завершила проверки успешно.

Для ПР01–ПР06 используется личный репозиторий. Начиная с командной части курса, ПР07–ПР14 можно выполнять в общем репозитории проекта: вклад каждого участника должен быть виден по commit и pull/merge request.

Что создаёте вы

В ПР01 создайте README с командами опыта, workflow и отчёт evidence. В ПР02 добавьте пакет turtle_bringup с launch-файлом и его сборку в CI. Собственные ноды и их функциональные тесты появляются с ПР03. Перечень ниже вводится постепенно, по условию каждой работы.

• ROS-пакеты и их метаданные (package.xml, CMakeLists.txt или setup.py);
• ноды, интерфейсы, launch/config-файлы и собственные тесты;
• workflow встроенного CI;
• evidence/prNN/ с командами, результатами и объяснением причины дефекта.

Условие, интерфейсные контракты, public checker, шаблон отчёта и входные данные скачивайте через версионированный course-kit. Если в условии указана модель, политика или детектор, интегрируйте и проверьте именно этот артефакт.

GitHub или GitVerse

Платформа	Где лежит workflow	Знакомство
GitHub Actions	.github/workflows/ci.yml	Quickstart for GitHub Actions
GitVerse CI/CD	.gitverse/workflows/ci.yml	Быстрый старт GitVerse CI/CD

Создайте пустой репозиторий на выбранной платформе, клонируйте его, добавьте свой workspace и сделайте первый push. После push откройте вкладку Actions на GitHub или CI/CD на GitVerse и прочитайте log каждого шага. Подробности container, событий и шагов есть в справочнике workflow GitVerse.

Минимальный workflow

Обе платформы понимают один и тот же базовый сценарий. Положите файл по пути из таблицы. Для ПР01 вместо шага Build and test используйте проверку JSON ниже и шаги скачивания kit / проверки evidence из следующего примера:

- name: Validate environment JSON
  shell: bash
  run: python3 -m json.tool evidence/pr01/environment.json > /dev/null

Живую доставку сообщений проверяйте локально по условию работы. Для ПР02 используйте шаг сборки из раздела ниже. С ПР03 выполняйте сборку и функциональные тесты пакетов:

name: ROS checks

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    container:
      image: osrf/ros:lyrical-desktop-full@sha256:e6b1cb530b65588279681db53784e264ce5cf83f2cc33e689d27d6024d7f3ebe
    steps:
      # Shell выполняется без Node; JavaScript actions требуют его заранее.
      - name: Prepare Node for checkout (GitVerse, linux-x64)
        shell: bash
        run: |
          test "$(uname -m)" = x86_64
          apt-get update
          apt-get install -y --no-install-recommends ca-certificates curl xz-utils
          curl -fsSLo /tmp/node.tar.xz https://nodejs.org/dist/v22.19.0/node-v22.19.0-linux-x64.tar.xz
          printf '%s  %s\n' c0649af18e6a24f6fe5535a3e86b341dd49a8e71117c8b68bde973ef834f16f2 /tmp/node.tar.xz | sha256sum -c -
          tar -xJf /tmp/node.tar.xz -C /usr/local --strip-components=1
          node --version
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Build and test
        shell: bash
        run: |
          source /opt/ros/lyrical/setup.bash
          colcon build --symlink-install
          colcon test --event-handlers console_direct+
          colcon test-result --verbose

В GitVerse JavaScript action checkout запускается командой node внутри выбранного контейнера. В ROS-образе Node.js может отсутствовать, поэтому shell-шаг выше стоит до checkout и устанавливает закреплённый Node 22 для x86_64. Контрольная сумма взята из официального выпуска Node.js. Установка выполняется от root в одноразовом контейнере CI. Node нужен и в завершающем Post checkout: не удаляйте его после сборки. setup-node тоже является JavaScript action и не решает отсутствие исполняемого node на старте.

Для проверенного Lyrical/Ubuntu 26.04 вместо загрузки архива подходит shell-шаг apt-get update && apt-get install -y --no-install-recommends nodejs, затем node --version: в проверенном прогоне установлен Node 22.22.1. Для Jazzy/Ubuntu 24.04 не переносите это предположение: версия Node в apt отличается. В образце выше версия выбрана явно для обеих ROS-сред.

Проверяйте весь job, включая завершающие шаги: локальная сборка ROS и checker не проверяют работу самого checkout. На облачном раннере GitVerse не рассчитывайте на вложенный docker run: доступ к docker.sock отсутствует. Используйте jobs.<job>.container, как в примере.

Этот образ соответствует selected.ros: lyrical в опубликованном baseline.lock.yaml. При обновлении среды одновременно сверяйте image digest и путь setup.bash с текущим выпуском; смешивать дистрибутивы в одном workflow нельзя.

Добавьте отдельный шаг, который скачивает зафиксированный недельный course-kit, проверяет .sha256.txt и запускает check_practice.py для текущей работы. Точный immutable URL и digest показывает GET /api/course-kit; перенесите их в workflow, не подставляйте там стабильную ссылку, которая обновится в следующий понедельник. VERSION и SHA-256 в локальном запуске, report.json и CI должны совпадать.

fetch-depth: 0 обязателен и на GitHub, и в совместимом workflow GitVerse: public checker сравнивает evidence-коммит с указанным в отчёте коммитом реализации, поэтому оба должны присутствовать в истории checkout.

Добавьте к workflow зафиксированные значения, показанные API для вашей недели:

env:
  COURSE_KIT_URL: https://ros.lms.ci.nsu.ru/downloads/robotics-course-kit-v1-wNN-<digest12>.tar.gz
  COURSE_KIT_SHA256: <полный-64-символьный-digest>

steps:
  - name: Download course kit
    shell: bash
    run: |
      curl -fsSLo course-kit.tar.gz "$COURSE_KIT_URL"
      printf '%s  %s\n' "$COURSE_KIT_SHA256" course-kit.tar.gz | sha256sum -c -
      mkdir -p .course-kit
      tar -xzf course-kit.tar.gz -C .course-kit
  - name: Check PR evidence
    shell: bash
    run: python3 .course-kit/v1/tools/check_practice.py PR01 --submission .

Замените NN, оба digest и PR01 точными значениями своей работы. Эти строки не являются секретами; токены доступа в workflow не записываются.

Поле report.json → commit содержит полный SHA коммита реализации — состояния с готовыми кодом, конфигурацией и тестами (в ПР01 — README с командами и workflow). Затем отдельным commit добавляются только evidence/prNN/ и обязательный AI_USAGE.md. Именно этот второй, evidence-коммит отправляется на проверку и должен иметь зелёный CI. Так отчёт может ссылаться на уже существующий SHA, а checker гарантирует, что после него не менялась реализация.

Пошаговый пример: два коммита и заполнение report.json.

Команда с ненулевым exit code должна останавливать workflow. Не добавляйте continue-on-error и не заменяйте тесты командой, которая только печатает OK. Cache может ускорять загрузку зависимостей, но проверка должна проходить и после чистого checkout.

Проверка пакета ПР02

В ROS-контейнере примера выше замените шаг Build and test на:

- name: Build PR02 launch package
  shell: bash
  run: |
    source /opt/ros/lyrical/setup.bash
    colcon build --symlink-install --packages-select turtle_bringup
    source install/setup.bash
    test -f "$(ros2 pkg prefix turtle_bringup)/share/turtle_bringup/launch/sim.launch.py"
    python3 -m py_compile src/turtle_bringup/launch/sim.launch.py

После него нужны скачивание зафиксированного kit и check_practice.py PR02 --submission ., как показано выше. Здесь используется Lyrical из образа примера. Для прежней работы на Jazzy образ и путь setup.bash должны относиться к Jazzy. Проверка наличия установленного файла выявляет забытый data_files; работоспособность GUI и остановку через Ctrl+C покажите локально. ROS-пакетов с собственной нодой в ПР02 ещё нет.

Что приложить к сдаче

1. Ссылку на репозиторий, доступный проверяющему.
2. Полный SHA проверяемого evidence-коммита.
3. Ссылку на успешный CI run именно для evidence-коммита.
4. Команду демонстрации и каталог evidence/prNN/.

Если после успешного run появился новый commit, нужно дождаться CI для нового SHA. Если он меняет реализацию, обновите report.json → commit и evidence. Badge ветки и скриншот зелёной галочки не заменяют ссылку на log.

Перед push не добавляйте токены, пароли, kubeconfig, приватные ключи, большие bag-файлы и каталоги build/, install/, log/. Секреты задаются только через настройки CI платформы.