Airflow Git в Airflow 3 удобно строить через GitDagBundle: он получает код DAG из выбранного Git-репозитория и связывает запуск с ревизией bundle. Команде нужны отдельные проверки загрузки файлов, парсинга DAG и фактической версии запуска. Такой маршрут подходит при доступе к разрешённому репозиторию и тестовом контуре, где можно проверить возврат к прежнему коду.
Граница маршрута
GitDagBundle в Airflow 3 поддерживает версионирование кода DAG: для запуска фиксируется версия bundle, связанная с коммитом Git.
Здесь Git служит источником кода для существующего Airflow 3. Репозиторий содержит файлы DAG и необходимые соседние файлы, а конфигурация bundle указывает, откуда Airflow их получает. После получения файлов процессор DAG должен разобрать определения задач. Затем команда сопоставляет конкретный запуск с записанной версией. Успешное получение репозитория само по себе подтверждает лишь доступность источника; синтаксическая ошибка, отсутствующая зависимость либо ошибочная логика остаются отдельными причинами отказа.
В официальной документации Airflow различаются версии DAG Bundle и состояние конкретного DAG run. Это важно при движущейся ветке: ссылка на ветку может указывать на новый коммит, пока прежний запуск сохраняет собственную записанную версию. Поэтому журнал релиза должен содержать ожидаемый commit SHA, фактически загруженную ревизию и идентификатор проверенного запуска. Одна строка «код обновлён» скрывает расхождения между этими событиями.
Тема отличается от подключения GitHub к ИИ-агенту: там агент читает облачный репозиторий, здесь сам Airflow получает исполняемые определения DAG. Разбор работы агента с репозиторием и PR поможет организовать человеческое ревью изменения, при этом разрешение на слияние кода подтверждает лишь завершение ревью, а парсинг проверяется в Airflow. Учебный Docker Compose и механизм git-sync в Helm chart решают иные задачи доставки и запуска.
Сверяйте настройки с официальной документацией Airflow DAG Bundles для установленной версии Airflow и Git provider. Текущая ветка документации может отличаться от вашего окружения.
Точка привязки
Для GitDagBundle в списке [dag_processor] dag_bundle_config_list задают класс airflow.providers.git.bundles.git.GitDagBundle и параметры источника. Среди них tracking_ref — ветка, тег либо commit SHA. Когда нужен воспроизводимый контроль конкретного выпуска, зафиксированный коммит упрощает сверку намерения с фактом. Движущаяся ветка требует отдельной записи ожидаемого SHA в журнале изменения. Выбор стратегии команда делает до проверки, чтобы слово «актуальный» имело проверяемый смысл.
Доступ к закрытому репозиторию оформляют через git_conn_id и Airflow Connection с разрешениями только на нужное чтение. Указание repo_url прямо в конфигурации возможно, но секреты в URL и в тексте DAG создают лишнюю поверхность раскрытия. Документация предупреждает, что параметры bundle могут попасть в Config API при соответствующей настройке. Поэтому владелец платформы проверяет права учётной записи, место хранения секрета и состав доступной конфигурации до подключения. Проверку разрешений выполняет сервер источника и контур Airflow, поэтому промпт остаётся описанием задачи без полномочий проверки.
На тестовом окружении фиксируют установленную версию Airflow, наличие Git provider, путь к DAG в репозитории и выбранный tracking_ref. Дополнительные subdir либо sparse_dirs допустимы при понятной структуре проекта; чрезмерно узкая выборка может исключить файл, который импортирует DAG. Локальный bundle без отслеживания версии подходит для другого режима доставки, поэтому его результат нельзя переносить на сценарий GitDagBundle. Если конфигурация отключает versioning, критерий сопоставления запуска с коммитом требует пересмотра.
Предложение для пилота — отдельный тестовый репозиторий с небольшим разрешённым DAG и копией настроек без секретов. Команда заранее назначает ответственного за репозиторий, платформу и приёмку DAG. Так проще различить отказ в доступе к Git, проблему импорта Python и ошибку обработки данных внутри задачи. Каждая причина требует собственного владельца и собственного доказательства исправления.
Проверка поставки
Рабочий маршрут полезно записать как последовательность наблюдаемых состояний. Сначала утверждают исходный коммит и изменение DAG. Затем тестовый Airflow получает bundle, процессор разбирает код, а контрольный запуск проходит с разрешёнными тестовыми данными. Только после этого владелец выпуска решает, подходит ли ревизия для рабочего контура. Полную картину даёт сопоставление результатов всех этапов.
- Зафиксируйте репозиторий, tracking_ref, ожидаемый commit SHA и владельца изменения. В ревью покажите diff DAG и связанных файлов, включая зависимости и настройки доступа.
- Подключите GitDagBundle в изолированном окружении. Проверьте получение файлов и доступ учётной записи к выбранной ревизии; при отказе сохраните код ошибки без токена и назначьте ответственного за разбор.
- Проверьте, что процессор DAG распарсил нужное определение. Сопоставьте список ожидаемых задач и импортов с фактическим DAG; успешную загрузку и успешный парсинг фиксируйте отдельно.
- Запустите разрешённую контрольную задачу на тестовых данных. Сверьте идентификатор DAG run, его записанную версию bundle и ожидаемый commit SHA. Результат задачи оцените отдельно от версии кода.
- Сохраните решение владельца выпуска, ссылку на ревью и признаки успешного либо отклонённого прогона. При расхождении версий остановите продвижение изменения и выясните, какой ref увидел Airflow.
Для полного журнала запусков и выгрузки статусов используйте скрипт или парсер: он сопоставит идентификаторы, версии и исходы по правилам команды. Языковая модель может объяснить найденное расхождение и предложить гипотезы, но инженер сверяет их с исходными записями и кодом. Это особенно важно, когда одинаковое название DAG скрывает разные версии исходников.
Проверка такого маршрута часто упирается в связь Git, процессора DAG и журнала запуска. В проекте автоматизации процессов границы ответственности и критерии приёмки лучше описать до переноса кода в рабочую среду.
Хотите проверить доставку DAG из вашего Git-репозитория?
Возврат ревизии
Откат здесь означает управляемый возврат источника DAG к заранее известному коммиту и новую проверку, что Airflow загрузил именно его. Способ зависит от выбранного tracking_ref: команда может закрепить прежний SHA либо изменить указатель ветки через утверждённый процесс Git. Перед решением нужно знать, какие DAG уже начали работу, какие ещё ждут запуска и какие данные успели изменить задачи. Побочные эффекты прошлых запусков требуют отдельного разбора и решения владельца данных.
Airflow хранит версию bundle у DAG run; поведение повторного запуска зависит от настроек выбора версии, включая rerun_with_latest_version, и доступности прежнего исходного кода. Поэтому отдельно проверяют новый запуск после возврата и повтор прежнего запуска, если такой сценарий предусмотрен. Обещание, что любая очистка задачи всегда исполнит прежний код, было бы слишком сильным. Фиксация версии позволяет задать проверяемый вопрос, а ответ даёт тест установленной конфигурации.
| Сбой | Что фиксировать | Решение команды |
|---|---|---|
| Git недоступен | Ref, признак отказа загрузки, состояние прежней версии | Восстановить разрешённый доступ и проверить загрузку в тестовом окружении |
| DAG отсутствует | Лог парсинга и список загруженных DAG | Исправить импорт либо путь и повторить парсинг |
| Версия расходится | Ожидаемый SHA и версия конкретного DAG run | Приостановить выпуск, выяснить источник версии и согласовать возврат |
| Задача дала ошибку | Версия запуска, входные тестовые данные, журнал задачи | Разобрать код и данные, затем подтвердить повторный прогон |
В плане возврата перечисляют владельца решения, точку остановки нового выпуска, проверенный прежний коммит и способ сверки после изменения ref. На тестовом контуре разыгрывают ошибку парсинга и несовпадение версии; фиксируют, где оператор видит причину и как подтверждает восстановление. Такой тест даст основание для решения о будущем пилоте, без обещания атомарного переключения и с описанием ожидаемых признаков результата будущего пилота.
Критерии приёмки
Приёмка должна связывать код и запуск. Запись об изменении содержит ссылку на ревью, ожидаемый SHA, настройки bundle без секретов, подтверждённый парсинг и идентификатор контрольного DAG run. Проверяющий открывает исходный коммит, затем смотрит версию bundle у запуска и результат задачи. Если значения расходятся, выпуск остаётся в статусе разбора. Такой порядок полезнее общей пометки «DAG работает», поскольку ошибка версии может проявиться даже при успешной задаче.
Отдельно проверяют права: учётная запись Git видит только согласованный репозиторий, а роль Airflow получает лишь нужные действия. На тестовом контуре предусматривают отказ при попытке получить чужой источник или запустить закрытый DAG. Владелец безопасности сверяет политику доступа на стороне Git и Airflow; текстовая инструкция агенту служит лишь описанием задачи. Журналы сохраняют технические признаки без паролей, токенов и содержимого чувствительных данных.
Экономику такой схемы оценивают качественно. На состав работ влияют устройство репозитория, число DAG, зависимости provider, место хранения секретов и требования к журналу выпуска. Отдельная статья про Docker Compose отвечает на вопрос локального учебного запуска; здесь предмет сметы — управляемая доставка версии и её проверка. Для предложения будущего пилота выберите один безопасный DAG, соберите эталон ожидаемых задач и согласуйте признаки успешного возврата. Затем команда сможет оценить объём интеграции по фактам своего контура.
Пилот можно считать готовым к оценке после сверки исходного SHA, версии DAG run, результата контрольной задачи и проверенного пути возврата на тестовом контуре. Финальное решение о рабочем выпуске остаётся за владельцем платформы.