softdevtools-dns

План проверки опубликованных сайтов для ЛР №5

Статус: спецификация для следующего PR; проверяющий скрипт и workflow пока не реализованы. Проверка YAML в PR и применение CNAME после merge уже работают. Студент выполняет работу через сайт GitHub; этот процесс работает на стороне репозитория и не требует инструментов на компьютере студента.

Задача и границы

После принятия заявки отдельно установить, что DNS-запись опубликована, домен привязан к нужному GitHub Pages и сайт отвечает по HTTP, а затем что HTTPS работает с проверенным сертификатом. Задержку DNS и выпуска сертификата показывать как ожидание. Технический статус не является оценкой студента.

Вход — только принятые records/*.yaml из доверенной main. Код из fork не исполнять. Для чтения публичного DNS, Pages и сайта Cloudflare API Token не нужен. Процесс не создаёт, не меняет и не удаляет DNS-записи.

Независимые результаты

Поле	passed	pending	failed
dns_live	Публичный CNAME равен target из заявки	Запись ещё не видна	Видна другая запись или другое значение
pages_domain	Публичный репозиторий сайта существует, а Pages сообщает нужный custom domain	Pages ещё публикуется или API временно недоступен	Домен привязан к другому сайту или репозиторий не соответствует заявке
site_live	HTTP (или переход на рабочий HTTPS) отдаёт страницу нужного сайта	Временная ошибка публикации, сети или разрешения имени	Устойчиво неверный адрес, опасное перенаправление или чужая страница
https_live	Обычный HTTPS-запрос проходит проверку имени и цепочки сертификата и отдаёт сайт	Сертификат ещё выпускается	Устойчиво неверная настройка после оговорённого срока ожидания

Каждый результат содержит checked_at, краткую машинную причину и безопасное объяснение для человека. not_checked допустим, когда предыдущий этап ещё не позволяет выполнить проверку. Ошибки одного сайта не останавливают проверку остальных заявок.

Как проверять

1. Повторно валидировать все заявки локальным scripts.validate.
2. Для каждой заявки собрать полное имя <subdomain>.softdevtools.ru и проверить CNAME через публичный DNS. Не принимать A/AAAA или CNAME на другую цель вместо ожидаемого username.github.io.
3. Проверить repository и custom domain через публичный GitHub Pages API. Схема заявки уже связывает владельца репозитория с target.
4. Ограничить HTTP-запросы доменом из заявки, таймаутом и числом переходов. Разрешать переход с HTTP на HTTPS того же имени; не ходить по ссылкам на произвольные хосты и не обращаться к локальным или закрытым адресам.
5. Не засчитывать один лишь код 200: нужно подтвердить содержимое нужной страницы. До реализации выбрать проверяемый признак. Возможный минимальный вариант — видимое на странице полное имя поддомена без изменения YAML-схемы. Пока это предложение, а не требование к студенту.
6. Выполнить отдельный HTTPS-запрос с обычной проверкой сертификата. Режим -k/insecure может быть только диагностикой преподавателя, не успехом.

Проверяющий процесс не должен передавать GitHub или Telegram токены в HTTP запросы к сайту студента и не должен печатать их в логах.

Запуск и повторение

• Сразу после успешного применения DNS делать первую проверку либо запускать её вручную из Actions. Немедленный результат часто будет pending.
• Повторять ожидающие случаи по schedule на доверенной main, ориентировочно раз в 15 минут, с отдельным workflow_dispatch для ручного повторения. Расписание GitHub Actions не гарантирует точную минуту запуска; не привязывать оценку или занятие к моментальному результату. См. описание событий GitHub Actions.
• Ограничить время одного HTTP-запроса и суммарное время задания; проверить нагрузку на ~96 заявок. Периодический запуск читает все принятые записи, если не появится надёжное хранилище состояния ожидающих проверок.
• Хранить сводку по каждому имени в машиночитаемом артефакте запуска и коротком GitHub Actions summary. Способ долговременного хранения последнего статуса и дедупликации уведомлений выбрать перед реализацией уведомлений.
• Преподавателю сообщать о случаях, требующих решения, без повторного сообщения на каждом проходе. Временный pending не должен выглядеть как ошибка студента.

Проверки будущего PR

• CNAME отсутствует, затем появляется и совпадает с заявкой.
• CNAME занят другой записью: явный failed, без попытки исправить DNS.
• Pages ещё собирает сайт; HTTP временно недоступен; HTTPS ещё не готов: статусы ожидания и успешный повторный проход.
• HTTP отдаёт 200, но не подтверждает нужное содержимое; внешний redirect; неправильное имя сертификата: успех не засчитывается.
• Несколько заявок: одна ошибка не скрывает результаты остальных.
• workflow_dispatch и расписание используют код из main; PR из fork не получает секреты и не запускает свой проверяющий код.

Решения перед реализацией

1. Какой обязательный признак страницы проверять автоматически: полное имя поддомена в видимом тексте, отдельное поле заявки или другое правило?
2. Когда pending превращается в проблему для преподавателя, особенно для HTTPS, и нужны ли разные сроки для DNS и сертификата?
3. Где хранить последний статус и как сообщать студенту и преподавателю о смене статуса без повторяющихся уведомлений?