Блог
У красного гейта не было входных данных
Смерженный аудит FPGA-репозитория показывает, как отсутствующий checkout превратил двенадцать непроверенных расхождений в видимость исправлений, а ещё два отказа оказались обычной проблемой раннера.
Подписи на изображении — на английском.
- THE VERDICTTwelve disagreements read as fixed.
- THE ABSENCEThe checkout never happened.
- THE LIMITTwo failures were plain plumbing.
Красный CI-гейт ещё не является finding. Он может сообщать о finding, а может оказаться проверкой, которой не дали объект для проверки.
PR #564 смержен в gHashTag/trinity-fpga. Тема узкая: три гейта, связанные с документами и артефактами, падали из-за собственной инфраструктуры, а два других оставили красными, потому что они сообщали о содержательных проблемах.
Опасный отказ вызвал отсутствующий checkout
Workflow artefact-agreement просил actions/checkout взять ../t27. GitHub Actions запрещает путь к репозиторию за пределами рабочей области checkout. При этом у шага стоял continue-on-error: true, поэтому задача продолжала работу без каталога, с которым должна была сравниваться.
После этого ratchet напечатал двенадцать расхождений baseline как [fixed]. Это слово не было открытием. Оно означало, что сравнение не запустилось. Смерженный коммит воспроизводит оба состояния: без входа гейт показывает мнимые исправления, а после восстановления входа сообщает OK: no new disagreements (13 known).
Отсутствующий вход должен останавливать проверку, а не выглядеть как согласие.
Рядом прятались два обычных отказа раннера
Decoder conformance и undefined-outputs оба запускали ./conform.sh, чей shebang — #!/bin/zsh. В Ubuntu-раннере zsh не было, поэтому обе задачи завершались с кодом 127 до того, как скрипты успевали что-либо сказать о дизайне. Исправление устанавливает zsh, а не молча переписывает скрипты репозитория на другой shell.
У проверки ссылок на документы была другая причина. Один документ называет /root/bitnet_h100_metrics.json. В pathlib соединение базового каталога с абсолютным путём отбрасывает базу, поэтому проверка пыталась читать /root раннера и получала PermissionError. Новый helper считает недоступные пути отсутствующими и позволяет проверке дойти до содержательных вопросов.
Чего мерж не решил
Два гейта намеренно не меняли: один по-прежнему сообщает об отозванном числе, другой — о двух артефактах-сиротах. Это содержательные решения, не plumbing. PR оставляет вопросы видимыми, а не делает dashboard зелёным удалением самих вопросов.
- Смерженные свидетельства подтверждают исправленный путь входных данных, но не корректность самих числовых заявлений.
- Двенадцать мнимых исправлений были следствием отсутствующего checkout, а не двенадцатью починенными расхождениями.
- 13 известных расхождений остаются baseline, за которым должен следить гейт.
- Квитанции этого поста — workflow и коммит; измерение на FPGA здесь не заявляется.
Полезная граница для красной проверки такова: прежде чем толковать её вывод, убедитесь, что у неё были вход, интерпретатор и пути к файлам. Иначе цвет сообщает о раннере, а не о работе.
Чего это не решает
- PR чинит инфраструктуру гейтов и воспроизводит отказ из-за отсутствующего входа, но не устанавливает, верны ли сами расхождения форматов. Два содержательных finding остаются открытыми.
- Правка checkout показана на workflow репозитория; отдельный свежий публичный прогон после мержа здесь не используется как самостоятельная квитанция.
- Установка zsh оставляет shell-скрипты репозитория без переписывания, но workflow не сравнивает их вывод с реализацией на другом shell.
- Обработка недоступного абсолютного пути документа как отсутствующего убирает исключение раннера, но не доказывает, что этот документ должен находиться в репозитории.
Пруфы
Поработаем вместе
Хотите так же проверить собственный дизайн?
Я аудирую RTL и строю независимые побитово точные модели, затем провожу результат через синтез и, когда это полезно, проверяю на плате Artix-7. Первый модуль проверки — бесплатно.