Как проверить согласованность сгенерированного веб-сайта с помощью рекурсивного разбора HTML

У меня есть проект с открытым исходным кодом, веб-сайт которого генерируется с помощью asciidoc и некоторых пользовательских скриптов в виде множества (тысяч) статических файлов, которые локально находятся в репозитории исходных файлов, копируются в другое рабочее пространство и загружаются в репозиторий в стиле github.io, а в конечном итоге отображаются как HTTP-сервер для просмотра браузерами по всему миру.

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

Платформа для сборки сайта в целом похожа на POSIX, хотя чаще всего агент, выполняющий регулярную работу, использует Debian/Linux. Возможно, различия в платформах вызывают “проблемы с доступностью страниц”; возможно, эта ошибка не зависит от платформы.

Я подумал о создании проверки для двух локальных каталогов, а также для конечного сайта, чтобы обойти все относительные ссылки (и/или абсолютные, начинающиеся с его доменного имени) и сообщить о всех сломанных страницах, чтобы я мог сосредоточиться на поиске причин их отказа и/или избежать публикации “плохих” итераций – так же, как с компиляторами, отладчиками и предупреждениями в других местах.

Общая идея заключается в использовании режима паука в wget, хотя любая другая командная утилита (curl, lynx…), скрипт на python, оболочка с sed и т.д. тоже подойдут. Конечно, это конкретное колесо было изобретено слишком много раз, чтобы я даже думал о создании своего собственного? Однако быстрая и поверхностная сессия гугления в пути не принесла хорошего результата.

Так что, предложения приветствуются 🙂

Как предложено в комментариях, инструмент htmlproofer с GitHub (или пакет ruby-html-proofer для Debian/Ubuntu) кажется подходящим решением проблемы или, по крайней мере, очень достойным первым шагом.

Исправления, относящиеся к рассматриваемому проекту, можно увидеть в этом пулл-реквесте и они включают в себя документацию по установке инструмента, обнаружение его с помощью configure.ac в PATH или предоставленное пользователем/вызвавшим, а также некоторые рецепты Makefile.am для вызова инструмента в местах, задействованных в сборке сайта, с параметрами, которые имеют смысл для проекта (или могут быть переопределены вызвавшим программу make).

Производительность очень изменчива, от нескольких минут на облачном агенте сборки до около 40 минут на ноутбуке. Изначально производительность снижалась из-за сетевых запросов, вовлеченных в проверку внешних ссылок по умолчанию (а их почти 2000), но, предположительно, опция --disable_external должна с этим справиться (по крайней мере, netstat -an не отображает никаких висящих соединений во время повторного запуска).