mtusi2026lab4/CONTRIBUTING.md

Работа через fork и pull request

1. После публикации преподавателем сделайте fork репозитория текущей лабораторной в своём аккаунте и clone своего fork. URL преподаватель выдаёт отдельно.
2. Создайте ветку solution/<group>-<surname> от исходной ветки skeleton. Ветка преподавателя и файлы контракта остаются основой проверки.
3. Для lab2–7 перенесите из своей предыдущей лабы только исходники, миграции, собственные тесты, Dockerfile и нужные конфигурации. Не копируйте .git, .env, credentials, volumes, README.md, COURSE.md, публичные tests/ и contracts/ поверх новой версии. Сначала сравните изменения API в COURSE.md.
4. Реализуйте задание, добавьте свою инструкцию запуска и заполните REPORT.md. Публичные проверки дополняйте отдельными тестами, не ослабляйте assertions.
5. Выполните make check, запустите свой стенд, затем make test. Выполните сценарии отказов текущей лабы. Их запуск всегда явный: scaffold сам не останавливает контейнеры.
6. Commit и push делайте в свой fork. Откройте PR в исходный репозиторий преподавателя, заголовок: ЛР N — Группа — Фамилия — на 3/4/5. Выберите правильную базовую ветку и заполните шаблон.
7. После замечаний обновляйте тот же PR. Чужие решения не переносите без указания источника и согласованных правил курса.

Платформа может называть PR «merge request» — процесс тот же. .github/ содержит необязательные удобства для GitHub; проверки локально от платформы не зависят. Инициализация и публикация исходных Git-репозиториев выполняются преподавателем отдельно.

Правила изменения skeleton

Не удаляйте обязательные endpoint, поля, рубрику и публичные проверки. Изменение контракта согласуйте отдельным комментарием/PR; обход тестов не является решением. Код приложения размещайте в src/ либо в принятой для языка структуре. Собственные тесты — student-tests/ или штатный каталог фреймворка. Ссылки на результаты проверки и команды запуска должны переживать clone на другой машине.

CI

Готовый GitHub workflow проверяет целостность контракта и синтаксис Python-проверок. Он не запускает отсутствующее приложение и не подтверждает оценку. Студент добавляет сборку своего приложения, запуск/готовность стенда и make test в отдельный job. Не используйте pull_request_target для запуска кода из fork, не выдавайте CI секреты или доступ к общему Docker-host.