11 ноября вышел стабильный BuildKit 0.35.0. В релизе улучшены повторные HTTP-загрузки, обновление отклонённых данных авторизации реестра и несколько сценариев кеширования. На Mentoring.digital объясняем изменения для сборок контейнеров и CI.
Повторы загрузок учитывают ответ сервера
HTTP-источники теперь повторяют временно неудачные запросы и учитывают заголовок Retry-After. Он позволяет серверу указать время ожидания перед новой попыткой. Сам по себе механизм повторов не гарантирует, что недоступный источник в итоге ответит успешно.
При авторизации в реестре BuildKit обновляет отклонённые учётные данные перед повтором запроса токена. Это правка обработки отказа, а не разрешение использовать просроченный или отозванный доступ без его восстановления.
Исправления кеша и Dockerfile frontend
Разработчики исправили экспорт удалённого кеша с неполными цепочками слоёв и сопоставление кеша при отсутствующих blob-объектах или альтернативных входных ключах. Также исправлены отдельные проблемы частичного чтения и продолжения загрузок в S3-кеше.
Встроенный Dockerfile frontend обновлён до 1.29.0. В нём есть трассировка Git-команд для Git-контекстов и источников ADD через аргумент BUILDKIT_GIT_DEBUG_COMMANDS=1; требуется BuildKit 0.35 или новее.
У Dockerfile также существует отдельный вариант 1.29.0-labs. Его новые --unset и FROM --reset относятся к Labs. Наличие стабильного BuildKit 0.35 не означает, что эти экспериментальные флаги входят в обычный frontend.
Как проверить обновление в своей сборке
Проверьте фактическую версию builder, а затем обычную сборку и повторную сборку с используемым кешем. Если применяется удалённый кеш, проверьте экспорт и последующий импорт в тестовом окружении. Сценарии временного отказа источника проверяйте на контролируемом стенде.
Сохраняйте обезличенный журнал и сравнивайте одинаковые входные данные. Работу builder и порядок перехода в CI можно разобрать с наставником по DevOps. Обновлять рабочую инфраструктуру ради проверки новости не требуется.
