Аналіз змін в кодовій бази Bun після перепису із Zig на Rust - Два місяці потому
Минуло два місяці відтоді, як Bun переписали на Zig. Минулого разу, коли я аналізував Bun, я намагався зрозуміти, що змінилося у вихідному коді. Сьогодні я вирішив подивитися, наскільки стабільно збирається Bun, і те, що я виявив, виявилося доволі несподіваним.
Тож я подумав: зроблю кілька запитів до GitHub API, витягну всі запуски workflow — і готово. Але все виявилося не так просто. Bun використовує BuildKite для CI, а цей сервіс має справжню алергію на прозорість. Для вибраних параметрів можна переглянути лише чотири сторінки збірок. Переконайтеся самі: https://buildkite.com/bun/bun/builds?branch=main
Технічно я міг би фільтрувати збірки за днями, перебирати кожну дату окремо й таким чином зібрати всі дані, але це надто багато роботи заради того, що можна описати простими словами. Якщо подивитися на збірки в BuildKite, можна помітити, що команда Bun не надто переймається тим, щоб усі збірки завершувалися успішно, і скасовує дуже-дуже багато із них з якихось причин. Можливо, вони скасовують CI для pull request, якщо в main уже потрапив новіший коміт, але це неочевидно. Для мене це повністю підірвало довіру до їхнього CI. Коли збірка падає, неможливо зрозуміти, який саме коміт спричинив збій.
Як я вже казав, для мене це виглядає доволі сумнівною практикою. Навіщо взагалі мати індикатор успішності, якщо ви його ігноруєте? Навіщо запускати CI, якщо ви все одно скасовуєте половину перевірок на півдорозі? Хіба ми як спільнота не пройшли через це ще 10–15 років тому? Тоді ми теж жертвували перевірками заради швидшої доставки змін, але згодом відмовилися від такого підходу, бо він виявився надто крихким. Чи означає це, що в Bun є бюджет на маркетингові трюки на кшталт переписування проєкту, але немає коштів на підтримку нового LLM-орієнтованого процесу розробки? Хіба не очевидно, що якщо ви генеруєте більше коду, то маєте запускати більше перевірок, а це коштує грошей? Швидкість сама по собі має свою ціну.
Для порівняння, як і минулого разу, візьмемо Node.js. Оскільки вони використовують GitHub Actions, я можу просто звернутися до GitHub API й проаналізувати дані. Починаючи з 1 квітня 2026 року, приблизно 92% запусків CI щотижня завершуються успішно. Ці показники майже не коливаються й тримаються біля середнього значення. Очевидно, що хтось системно займається інженерією процесу збірок.
Якщо раніше я не робив жодних висновків і, можливо, говорити про Bun було ще зарано, то тепер бачу таке: дисципліна, з якою організація підходить до інженерних практик, важливіша за те, якою мовою написаний проєкт. Bun, ви погано популяризуєте якісні інженерні практики. Будь ласка, робіть краще.