# Настройка GIT-задач GIT — задачи, где каждая команда получает собственный Git-репозиторий (fork шаблона) на GitLab, GitHub или SourceCraft. Подходит для хакатонов, проектных соревнований и задач с автоматической проверкой через CI/CD. ## Когда использовать - Хакатоны с командной разработкой - Соревнования, где участники пишут код в репозитории - Задачи с автоматической проверкой через CI/CD пайплайны - Проектные задачи с code review ## Принцип работы ``` 1. Организатор создаёт шаблонный репозиторий (template) 2. Организатор настраивает Git-интеграцию в задаче 3. Участник нажимает «Создать репозиторий» 4. Система создаёт fork шаблона для команды 5. Участники получают доступ и работают в своём репозитории 6. (Опционально) CI/CD пайплайн проверяет решение ``` ## Поддерживаемые провайдеры | Провайдер | Аутентификация | Особенности | |-----------|---------------|-------------| | **GitLab** | PRIVATE-TOKEN | Полная поддержка групп, подгрупп, CI/CD | | **GitHub** | Bearer Token | Организации, Teams, GitHub Actions | | **SourceCraft** | Bearer Token | GitLab-совместимый API | ## Создание GIT-задачи ### Шаг 1: Создайте задачу | Поле | Описание | Обязательное | |------|----------|--------------| | **Название** | Название задачи | Да | | **Тип** | Выберите **GIT** | Да | | **Условие** | Описание задачи (Markdown) | Да | | **Баллы** | Максимальное количество баллов | Да | | **Порядок** | Позиция в треке | Да | Сохраните задачу, затем откройте её для редактирования — появится форма настройки Git-интеграции. ### Шаг 2: Подключение к провайдеру | Поле | Описание | |------|----------| | **Провайдер** | GitLab, GitHub или SourceCraft | | **Base URL** | URL API провайдера (например, `https://gitlab.example.com`) | | **API Token** | Сервисный токен с правами на создание групп и проектов | Нажмите **Проверить подключение**, чтобы убедиться, что токен работает. ### Шаг 3: Настройка пространства имён | Поле | Описание | Пример | |------|----------|--------| | **Root Namespace** | Корневая группа/организация | `codenrock` | | **Namespace** | Подгруппа для этой задачи | `hackathon-2026-backend` | | **Repository Slug** | Имя fork-а для каждой команды | `solution` | Кнопка **Заполнить по умолчанию** автоматически сгенерирует значения из названия соревнования и задачи. **Структура на провайдере:** ``` Root Namespace/ Namespace/ template-repo ← шаблонный репозиторий team-alpha/ ← подгруппа команды solution ← fork шаблона team-beta/ solution ``` ### Шаг 4: Шаблонный репозиторий Шаблонный репозиторий — это основа, которую получит каждая команда. Он может содержать стартовый код, тесты, CI/CD конфигурацию. Нажмите кнопку **Создать шаблонный репозиторий**. Система создаст пустой репозиторий с README в настроенном пространстве имён. После создания ссылка на шаблон отобразится в форме. Перейдите по ней и наполните репозиторий нужным содержимым: - Стартовый код / boilerplate - Тесты для автопроверки - `.gitlab-ci.yml` или `Dockerfile` для CI/CD - `README.md` с инструкциями для участников ### Шаг 5: Дополнительные настройки | Поле | Описание | |------|----------| | **Webhook Secret** | Секрет для верификации webhook-ов от провайдера | | **Режим скоринга** | Отключён / По результатам CI/CD / Трёхфазный | | **Защищённые ветки** | Ветки, в которые нельзя пушить напрямую (например, `main`) | **Режимы скоринга:** | Режим | Описание | |-------|----------| | **Отключён** | Баллы выставляются вручную | | **По результатам CI/CD** | Баллы рассчитываются из статуса пайплайна | | **Трёхфазный** | Build, Inference, Scoring — полный цикл автопроверки | ### Шаг 6: Сохранение Нажмите **Сохранить интеграцию**. Интеграция станет активной, и участники смогут создавать репозитории. ## Что видит участник После настройки интеграции участник видит на странице задачи: | Состояние | Что отображается | |-----------|-----------------| | **Нет команды** | Сообщение «Нет команды» | | **Не начато** | Кнопка **Создать репозиторий** | | **Создаётся** | Спиннер «Создание репозитория...» | | **Готово** | Ссылка на репозиторий + Clone URL | | **Ошибка** | Сообщение об ошибке + кнопка повтора | ### Процесс для участника ``` 1. Участник открывает задачу 2. Нажимает «Создать репозиторий» 3. Система создаёт подгруппу для команды 4. Форкает шаблон в подгруппу 5. Добавляет всех членов команды с правами WRITE 6. Участник переходит по ссылке и начинает работу ``` ## Управление доступом ### Организаторы Организаторы автоматически получают доступ **MAINTAINER** к пространству имён задачи. Это позволяет видеть все репозитории команд, просматривать код, запускать пайплайны. Доступ синхронизируется автоматически: | Действие на платформе | Что происходит на провайдере | |---|---| | Добавить организатора (EDIT/OWNER) | Получает MAINTAINER доступ ко всем GIT-задачам | | Удалить организатора | Доступ отзывается | | Понизить до VIEW/CURATOR | Доступ отзывается | | Повысить до EDIT/OWNER | Доступ восстанавливается | ### Участники Система автоматически добавляет всех членов команды с правами **WRITE** в репозиторий при его создании. **Поиск пользователей на провайдере (при SSO):** | Приоритет | Метод | Когда работает | |-----------|-------|---------------| | 1 | Поиск по внешнему ID пользователя | Требуется admin-токен | | 2 | Поиск по email | Требуется admin-токен | | 3 | Поиск по username (производный от email) | Работает с обычным токеном | Для надёжного добавления участников при SSO рекомендуется использовать **admin-токен** провайдера. ## CI/CD интеграция ### GitLab CI/CD Добавьте `.gitlab-ci.yml` в шаблонный репозиторий: ```yaml stages: - build - test build: stage: build script: - echo "Building..." - make build test: stage: test script: - echo "Running tests..." - make test ``` ### GitHub Actions Добавьте `.github/workflows/check.yml`: ```yaml name: Check Solution on: [push] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - run: make test ``` ### Webhook для результатов Платформа принимает webhook-и от провайдера для обновления статуса пайплайнов: | Событие | Действие | |---------|----------| | **Push** | Обновляет `lastPushAt` репозитория | | **Pipeline/Workflow** | Создаёт/обновляет результат пайплайна | ## Архивация При завершении соревнования система автоматически: - Защищает все ветки репозиториев (read-only) - Отзывает доступ всех участников и организаторов на провайдере - Помечает группы и репозитории как `ARCHIVED` Архивация необратима — участники больше не смогут пушить код. ## Пример задачи **Название**: Backend API Challenge **Условие**: ```markdown Реализуйте REST API для управления задачами (todo list). ## Требования - CRUD операции для задач - Фильтрация по статусу - Пагинация - Документация API (Swagger/OpenAPI) ## Стек Любой язык и фреймворк. В шаблоне — Go + Chi. ## Оценка CI/CD пайплайн запускает тесты автоматически. - Все тесты пройдены: 80 баллов - Code review: до 20 баллов ## Как начать 1. Нажмите «Создать репозиторий» 2. Клонируйте репозиторий 3. Изучите README.md и тесты 4. Реализуйте API 5. Пуш в main запускает проверку ``` **Настройки:** - Провайдер: GitLab - Namespace: `hackathon-2026/backend-challenge` - Скоринг: По результатам CI/CD - Защищённые ветки: `main` - Баллы: 100 ## Частые ошибки | Ошибка | Последствие | Решение | |--------|-------------|---------| | Токен без прав на создание групп | Ошибка при создании репозитория | Выдайте токену `api` scope | | Нет шаблонного репозитория | Участники получают пустой fork | Создайте и наполните шаблон до старта | | Не настроен SSO | Участники не находятся на провайдере | Убедитесь, что SSO работает для всех | | Слишком широкие права | Участники видят чужие репозитории | Используйте подгруппы для изоляции | ## Частые вопросы **В: Участник не может получить доступ к репозиторию. Что делать?** О: Проверьте, что пользователь залогинен на провайдере через SSO. Если используется обычный токен (не admin), система ищет по username — убедитесь, что username на провайдере совпадает с производным от email. **В: Можно ли изменить шаблон после того, как команды создали fork?** О: Да, но изменения не попадут в существующие fork-и. Участникам нужно будет вручную подтянуть изменения через `git pull upstream`. **В: Как добавить нового члена команды в уже созданный репозиторий?** О: Доступ выдаётся автоматически при создании репозитория для всех текущих членов команды. Если участник присоединился позже, его нужно добавить вручную на провайдере. **В: Организатор не видит репозитории команд. Что делать?** О: Убедитесь, что организатор добавлен с уровнем EDIT или OWNER. Доступ VIEW и CURATOR не даёт прав на Git-провайдере. Если организатор был добавлен до создания интеграции — его доступ был выдан автоматически. Если после — доступ синхронизируется при добавлении. **В: Поддерживается ли приватный GitLab?** О: Да. Укажите URL вашего GitLab в поле Base URL и используйте токен с вашего сервера. ## Связанные статьи - [Создание задач](/docs/organizer/tracks-tasks/create-tasks) - [Настройка CODING-задач](/docs/organizer/tracks-tasks/coding-task-setup) - [Настройка FILE-задач](/docs/organizer/tracks-tasks/file-task-setup) - [Управление участниками](/docs/organizer/community/participants)