Перевірила CI‑хук git‑сервера, знайшла 2 дефекти

Ситуація. Власний git‑сервер приймає пуші й може запускати хук на боці сервера, щоб відхиляти зміни, які не проходять гейт. Серверний хук — єдина частина автоматизації, яку неможливо випробувати локальним запуском: він виконується в bare‑репозиторії без робочого дерева, у середовищі, яке задає git‑сервер, і зчитує надіслані посилання зі свого стандартного входу. Прочитати скрипт і вирішити, що він правильний, — це лише здогад.

Завдання. Хук треба було відрепетирувати на справжньому bare‑репозиторії та справжньому пуші, перш ніж йому довіряти, а не розгорнути й виявляти проблеми вже в роботі.

Дія. Репетиція створює bare‑репозиторій, встановлює хук, клонує репозиторій, робить коміт і пуш, а потім перевіряє і сценарій прийняття, і сценарій відхилення. Вона виявила два дефекти, жодного з яких не було видно у файлі. Перший — резервний варіант в обробці аргументів: коли хук не міг визначити посилання, він підставляв заповнювач, який не відповідав жодному об’єкту, а оскільки значення надходить на стандартний вхід хука, а не як параметр, збій проявлявся значно далі як не пов’язана з ним помилка. Другий варто запам’ятати. Викликаючи хук, Git експортує змінну середовища, яка вказує на каталог репозиторію, і цю змінну успадковує все, що запускає хук. Гейт вивантажує надіслану ревізію й запускає в ній набір тестів, а набір тестів успадкував вказівник на bare‑репозиторій, — тож дев’ятнадцять тестів, які працюють із git, зверталися не до того репозиторію й ставали червоними на правильному коді. Середовище треба очищати на межі, а цю межу не видно, доки все не запустять насправді.

Результат. Хук працює в обох сценаріях, і обидва дефекти знайдено ще до того, як на них натрапив справжній пуш. Обмеження в тому, що репетиція — це все одно симуляція: вона доводить, що хук витримує один тип пушу, а робочий git‑сервер отримує пуші, яких ця репетиція не відтворює, зокрема примусові оновлення та видалення гілок.