Ребят не напомните какая настройка отвечает за одновременное кол-во запущенных тасков в даге?

никая
если хочешь ограничить то сделай pool

если коротко ответить, то - да.
но если более обстоятельно: версия дага меняется только при изменении параметров дат запуска (start, end, schedule), чтобы шедулер смог корректно построить план выполнения нового дага. Об этом, кстати, в доке к airflow сказано.
В этом случае да, висит старая версия дага в интерфейсе, которая не будет работать, её можно удалить либо ручками, либо раз в час её удалит наш скрипт, который подчищает такие orphan-даги

Продолжаю осмыслять ваш подход. А что вы делаете с динамически генерируемыми дагами? Или у вас таких нет? Я спрашиваю, т.к. мне кажется, что конфигурирование GitHub Actions и тому подобных, может оказаться весьми нетривильной задачей. Или вы как-то хитро деплоете даги из гита в s3?

Динамические даги есть. Но это ровно те же даги, которые описываются теми же dag-файлами и питон-кодом. Просто даги генерятся на уровне кода. С деплоем это не имеет ничего общего.
На счет деплоя: после того, как код стягивается с гита на сервер сборок (curcle ci), вызывается несложный скрипт на питоне, который копирует файлы с дагами на s3

Я всё про автоверсии дагов думаю. Вы ведь, если я правильно понял, автоматически добавляете версию (хэш коммита?) и название ветки из git-a к dag_id в CircleCI перед тем как копируете файлы на s3. И, как мне кажется, для автогенерируемых дагов, это может быть несколько сложнее. Или я всё неправильно понял? :)

Не совсем так. Версия указывается вручную в коде дага

Но если так, то возвращаемся к первому вопросу: почему не тянуть напрямую из гита? Вроде, несложно разные ветки сканировать на предмет новых дагов. Ровно в таком же sidecar контейнере, в котором сканируется s3...

Ни в коем случае не критикую, пытаюсь разобраться.

что в данном случае будет являться триггером для деплоя?

Тэг какой-нибудь к коммиту, вызов вручную пайплайна, вариант всегда найдётся)

Тэг к коммиту у нас

Кстати, а как много у вас дагов? Стоит ли задача автоматизированно отключать/удалять предыдущие версии?

Около сотни. Старые чистятся раз в час другим дагом)

Мы просто большинство дагов генерируем динамически на основе статуса источника данных, который храним не в бд Airflow.

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

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

Тэг к коммиту у нас

Вот, да, попробую так сделать. Контейнер будет спрашивать последний коммит раз в N секунд, и, если увидит нужный тэг, будет подтягивать новые даги. Имхо, особой разницы дергать s3 или git всё же нет.

Есть. Любой кривой коммит в гит ломает весь ваш DE😁