Вопрос, почему в один даг не объединить

У меня кейс: есть месячный пайплайн, а в конце квартала запускается другой квартальный и триггерит ещё раз 3 месячных

Чаще всего триггер нужен, если один даг может запускаться разными дагами

А, ну да, как я и написал. Когда один даг шерится между несколькими другими

Ну там не несколько, просто надо повторить иногда)

Архитекторы пытаются ввести новые стандарты, по ним каждая сущность должна формироваться в отдельном даге. А связать их как-то надо, так как между ними зависимости и все дела :с

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

Добро пожаловать в самое дружелюбное комьюнити.

Всем привет!
Есть airflow на k8s, есть отдельный репозиторий с dag-ми, которые забираются через git sinc, но хочется уйти от единого репозитория для dag-ов, что бы каждый проект/репозиторий содержал в себе dag и тут возникает вопрос, как их деплоить?

Добрый день. Хочу обновлять функцию, вызываемую python_callable в PythonOperator, без рестарта сервиса airflow-webserver. Как это лучше сделать? моё предположение, что через импорт самописной библиотеки, но тогда, где её хранить - хотелось бы рядом с dag-ами, но как тогда определять путь, если текущая директория новая для каждого запуска  dag-a (по крайней мере pwd в BashOperator каждый раз возвращает новый путь в /tmp)

git sync для каждой репы?

git sync вроде для одной репы настраивается

А так можно и что надо делать при добавлении нового репозитория, есть какие-то статьи/примеры?

ну имею ввиду контейнеры с гитсинком под каждую репу
ну и в директорию с дагами сделать папку под каждую репу

но вообще мне кажется стоит подумать, действительно ли так надо много репозиториев с дагами)

Будут большие боли с cicd

Андрюха, оставь одну репу

Можно попробовать через submodule

Привет Влад, я бы с радостью, но это не мое решение... Вот и пытаюсь придумать велосипед)))

ох, намучаются с ними тоже