Как Elasticsearch поломал сборки и «обнулил» звёзды в Github

Казалось бы, майская история с Docker hub должна была научить всех нас уделять больше времени на обеспечение целостности артефактов проекта, но на то мы и люди, чтобы учиться на своих (и чужих) ошибках не с первого раза. В этой статье я поведаю про настоящую историю, которая в этот раз не связана с образами, но связана с библиотеками.

Обыкновенный вторник второй половины октября, через час запланирован релиз в продакшн, ничего не предвещало, а ожидаемые заказчиком фичи уже протестированы вдоль и поперёк, ожидая своего часа.

В какой-то момент от коллег поступает информация о том, что официальная библиотека elasticsearch-php в момент сборки через composer install перестала устанавливаться.

Ринувшись разбираться в вопросе, выясняем, что Github репозиторий удален и теперь там красивая ошибка 404.

Как же так? Что произошло? Вот так просто удалить без какого-либо анонса? Что-то здесь неладное…

Работать нужно, но работать не дают, начинаем гуглить и искать интересующую нас информацию по сообщениям в чатах Telegram. Находим ссылку в дискуссиях на официальном ресурсе компании, где представитель команды сообщил, что часть публичных репозиториев временно недоступны, там же прикреплена ссылка на страницу с логами по инциденту.

Фрагмент логов, проясняющих ситуацию:

As part of an internal change task, some of our public git repositories hosted under Elastic’s GitHub organisation were marked as private. As a result, when attempting to access these repositories an error may be seen. Our teams are working to restore these with urgency.

Перевод: В рамках внутренней задачи по изменению некоторые из наших публичных репозиториев git, размещенных в организации Elastic GitHub, были помечены как приватные. В результате при попытке доступа к этим репозиториям может возникнуть ошибка. Наши команды работают над их срочным восстановлением.

Первое о чем я подумал, вспоминая свой предыдущий опыт смены видимости репозитория с Public на Private: «кажется, сейчас elastic потерял заработанные годами звёзды» (механизм смены видимости репозитория в Github работает по методу удаления и создания заново со сбросом числовых значений в шапке).

Релиз на носу, а с поиском что-то нужно делать, любой ценой катим фичи.. Учитывая, что поиск на проекте это не основной функционал, а вспомогательный, принимается решение удалить зависимость с бэкенда и визуально скрыть форму поиска для пользователей — composer remove в помощь. Управились быстро, релиз спасён, основные фичи поехали в продакшн без задержек по времени.

Уже вечером, после работы, с чашечкой чая, мне стало интересно, а что еще из популярного у Elastic было затронуто, начинаю изучать их репозитории. Подведя итоги, сравнив количество звёзд в Яндекс кэше, получаю следующий результат (актуально на момент написания статьи 30.10.24):

Пример на репозитории elasticsearch: факт и кэш Яндекс

Вам очень повезло, если процесс сборки на вашем проекте настроен по всем канонам безопасности, вы — молодцы! Возможно, вы просто не заметили данное событие, но это тоже хорошо.

На момент написания данного текста все известные мне (официальные) репозитории Elastic были восстановлены.

Под конец статьи хочу сказать следующее: берегите то дело, ради которого мы тратим столько сил и энергии, берегите ваши проекты и ваших заказчиков. Относитесь серьезно к процессу сборки и созданию резервных копий.

Это моя первая статья на данной площадке, в будущем постараюсь снабжать вас интересным контентом и новостями из мира IT.

Спасибо за внимание, Хабр!