Мы фиксируем точный тег и причина ровно та, которую вы сами назвали в итогах: интерфейс изолирован, а рантайм общий и приоритеты переменных переезжают тихо.
Что этот страх сняло -перестали смотреть на исходники модуля и стали смотреть на итоговый пайплайн. У GitLab есть GET /projects/:id/ci/lint: он валидирует .gitlab-ci.yml самого проекта с уже раскрытыми include и отдаёт merged_yaml, то есть ровно тот конфиг который поедет.
Одна оговорка: сравнивать merged_yaml текстом бесполезно. После рефакторинга модуля он переписывается целиком: другой порядок ключей, раскрытые extends, переехавшие якоря, — дифф красный весь, читать нечего. А настоящее изменение бывает в одну строку в variables и в этом шуме теряется. Нужен разбор в дерево и сравнение по путям, тогда остаётся что-то вроде "в джобе build IMAGE_NAME теперь приезжает не оттуда".
Вы merged_yaml где-то фиксируете, артефактом, отдельной джобой, в MR? Или сверяете уже по факту, когда что-то отвалилось?
Починил у себя, правило вышло такое: ячейка становится числом, только если при этом ничего не теряется. Ведущие нули, слова, которые f64 принимает за число, и целые длиннее i64 остаются текстом. Пока правил, вылезли ещё два случая: имя Nan превращалось в NaN, и неизменившаяся ячейка показывалась как изменённая, потому что NaN не равен сам себе; два 20-значных номера счёта, отличавшиеся последней цифрой, схлопывались в одно число. Маркер :: закрывает это честнее, но только когда о нём вспомнили. Не думали про предупреждение на plain-скаляр с ведущим нулём, чтобы человек узнал о потере сразу?
Про форматтер согласен, хук, стирающий комментарии, никто не поставит. Есть вариант, который файлы не трогает: канонический вид можно отдать гиту через .gitattributes как textconv, тогда git log -p, git show и git blame сравнивают нормализованный текст, а в рабочей копии всё остаётся как написано, вместе с комментариями. Для git diff нужен отдельный external diff driver, textconv туда не подключается. Бинарник, печатающий канонический вид, для этого всё равно нужен, то есть упирается в тот же CLI.
Про 00544 прямо в точку. После статьи проверил свою утилиту для сравнения конфигов, она тоже разбирает CSV в дерево и угадывает числа по виду. Замена 00544 на 544 у меня считается «без изменений», то есть баг ровно этот, пошёл чинить.
Вопрос про canonical.ktav: канонический вид есть только в тестах или его можно получить отдельной командой, вроде fmt? Её бы в pre-commit, чтобы дифф в git не зависел от того, кто записал объект в одну строку, а кто блоком.
Мы фиксируем точный тег и причина ровно та, которую вы сами назвали в итогах: интерфейс изолирован, а рантайм общий и приоритеты переменных переезжают тихо.
Что этот страх сняло -перестали смотреть на исходники модуля и стали смотреть на итоговый пайплайн. У GitLab есть GET /projects/:id/ci/lint: он валидирует .gitlab-ci.yml самого проекта с уже раскрытыми include и отдаёт merged_yaml, то есть ровно тот конфиг который поедет.
Одна оговорка: сравнивать merged_yaml текстом бесполезно. После рефакторинга модуля он переписывается целиком: другой порядок ключей, раскрытые extends, переехавшие якоря, — дифф красный весь, читать нечего. А настоящее изменение бывает в одну строку в variables и в этом шуме теряется. Нужен разбор в дерево и сравнение по путям, тогда остаётся что-то вроде "в джобе build IMAGE_NAME теперь приезжает не оттуда".
Вы merged_yaml где-то фиксируете, артефактом, отдельной джобой, в MR? Или сверяете уже по факту, когда что-то отвалилось?
Починил у себя, правило вышло такое: ячейка становится числом, только если при этом ничего не теряется. Ведущие нули, слова, которые f64 принимает за число, и целые длиннее i64 остаются текстом. Пока правил, вылезли ещё два случая: имя Nan превращалось в NaN, и неизменившаяся ячейка показывалась как изменённая, потому что NaN не равен сам себе; два 20-значных номера счёта, отличавшиеся последней цифрой, схлопывались в одно число. Маркер :: закрывает это честнее, но только когда о нём вспомнили. Не думали про предупреждение на plain-скаляр с ведущим нулём, чтобы человек узнал о потере сразу?
Про форматтер согласен, хук, стирающий комментарии, никто не поставит. Есть вариант, который файлы не трогает: канонический вид можно отдать гиту через .gitattributes как textconv, тогда git log -p, git show и git blame сравнивают нормализованный текст, а в рабочей копии всё остаётся как написано, вместе с комментариями. Для git diff нужен отдельный external diff driver, textconv туда не подключается. Бинарник, печатающий канонический вид, для этого всё равно нужен, то есть упирается в тот же CLI.
Про 00544 прямо в точку. После статьи проверил свою утилиту для сравнения конфигов, она тоже разбирает CSV в дерево и угадывает числа по виду. Замена 00544 на 544 у меня считается «без изменений», то есть баг ровно этот, пошёл чинить.
Вопрос про canonical.ktav: канонический вид есть только в тестах или его можно получить отдельной командой, вроде fmt? Её бы в pre-commit, чтобы дифф в git не зависел от того, кто записал объект в одну строку, а кто блоком.