Источники Git и Build Workers

Настройте коннектор по руководству Git-хостинги. Там также разделены права на репозиторий и права на целевой ресурс для запуска сохранённых сборок и просмотра истории. Учётные данные реестров описаны в разделе Реестры образов.

Источник Git связывает одобренную ревизию репозитория с неизменяемым артефактом сборки. Он может поставлять артефакт для Docker Container, Deployment или релиза Pages, но рабочая нагрузка всё равно следует жизненному циклу владеющего ресурса. Само подключение источника не даёт права менять Route рабочей среды или цель трафика.

Решите, что разрешено автоматизации

Разделите три решения: кто может читать исходный код, что считается одобренным артефактом и можно ли развёртывать этот артефакт автоматически. Так команда сможет автоматизировать обычные релизы, не выдавая webhook репозитория неограниченные полномочия в рабочей среде.

Владелец источника управляет доступом к репозиторию и выбирает коммит для сборки. Владелец платформы отвечает за Build Worker, политику сборки, реестр и целевой ресурс развёртывания. Владелец сервиса задаёт критерии приёмки и отката. Gateway связывает эти записи и сохраняет происхождение от коммита до дайджеста, но успешная сборка остаётся лишь входными данными для релиза.

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

Предварительные условия и владение

Используйте поддерживаемую интеграцию источника из списка разрешённых и выдавайте только необходимый для сборки доступ к репозиторию. Выберите точную ревизию ветки и убедитесь, что назначенный выделенный Build Worker подключён. Build Worker принимает одну сборку за раз, использует изолированное состояние BuildKit и containerd, применяет фиксированные ограничения ресурсов, запрещает небезопасные разрешения сборки и очищает кэш между заданиями.

Build Secrets ограничены источником и подключаются как секреты только во время сборки. Не помещайте учётные данные в аргументы сборки, ссылки на образы, URL репозитория, сохранённую в репозитории конфигурацию или журналы. Build Worker отвечает за изоляцию выполнения, реестр хранит созданный артефакт, а целевая нода Docker позднее загружает и запускает этот артефакт.

Соберите и проверьте артефакт

1. Подключите интеграцию и выберите репозиторий, ветку и нужную ревизию.
2. Настройте входные данные сборки и Build Secrets, ограниченные источником.
3. Запустите сборку и следите за её Task от назначения Build Worker до публикации артефакта.
4. Проверьте очищенные журналы, найденные уязвимости, результат политики, исходный коммит и неизменяемый дайджест артефакта.
5. Выберите одобренный дайджест в сценарии владеющего Container, Deployment или Pages.

Автоматическая сборка и автоматическое развёртывание — независимые настройки. Не включайте автоматическое развёртывание, пока для рабочей нагрузки не проверены состояние и путь отката. Успешная сборка доказывает только наличие артефакта, но не подтверждает, что приложение корректно запустится на целевой ноде.

Обработка сбоев

Если сборка не начинается, откройте её Task и проверьте авторизацию источника, доступность Build Worker, право по тарифу и состояние интеграции. Если ошибка произошла после запуска, по этапу и журналам отделите сбой зависимости, секрета, политики, определения сборки или публикации артефакта. Исправьте источник или конфигурацию и запустите новую сборку. Повторная попытка создаёт новую операцию и сохраняет прежнюю историю.

Если Build Worker или автоматизация источника недоступны, прежняя история остаётся полезной для диагностики, но новые сборки нельзя считать выполняющимися. Не заменяйте отсутствующий неизменяемый артефакт изменяемым тегом образа. Дождитесь проверенной сборки или используйте отдельно одобренный образ.

Очистка и откат

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

Критерии успеха

Приемлемая сборка указывает репозиторий и точный коммит, завершается на одобренном Build Worker, создаёт неизменяемый дайджест, проходит настроенную политику уязвимостей и показывает журналы без секретов. Приёмка Deployment выполняется отдельно: целевой ресурс должен загрузить дайджест, успешно запуститься, пройти проверку состояния и обслужить ожидаемый клиентский путь.

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

Операторские детали: изоляция и диагностика

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

Если сборка находится в очереди, отделите нехватку ёмкости Build Worker от ошибки источника или политики. Если она запустилась и завершилась ошибкой, определите фазу: получение исходного кода, разрешение зависимостей, сборку Dockerfile или Compose, проверку уязвимостей, публикацию в реестр или итоговое подтверждение. До повторной попытки сохраните ограниченный фрагмент журнала и коммит. Повтор должен создать новую аудируемую попытку, а не перезаписать неуспешную запись.