Zespoły i deploy przez git

W większych organizacjach rzadko chce się, żeby każdy użytkownik mógł edytować każdy DAG. Model zespołów w DagSmith wiąże uprawnienia z katalogiem wewnątrz bundle'a DAGów.

Jak działają zespoły

• Admin tworzy zespół: zbiór userów-członków plus przypisany podkatalog (bundle + path_prefix — przy nakładających się podkatalogach wygrywa najdłuższy prefiks).
• Tylko członkowie zespołu (lub skonfigurowani admini) mogą tworzyć i edytować drafty w tej ścieżce; deploy i git-push są egzekwowane tak samo.
• Nowe DAGi tworzone przez członka zespołu lądują w katalogu zespołu i dostają tag team:<nazwa>, dzięki czemu natywna lista DAGów w Airflow da się filtrować po zespole.
• Admin może w każdej chwili przypisać pojedynczy plik do innego zespołu — to przypisanie wygrywa nad dopasowaniem po prefiksie ścieżki.

Admini (skonfigurowani przez [dagsmith] admins) omijają ograniczenia zespołów całkowicie; jeśli ta lista jest pusta, deployerzy są traktowani jak admini.

Git przy deployu

Deploy zawsze zapisuje do własnego checkoutu bundle'a DAGów — jeśli to repozytorium git i ustawiono git_commit = True, DagSmith commituje z Tobą jako autorem. Dzieje się to niezależnie od zespołów.

Zespół może dodatkowo mieć własny zdalny git (git_remote_url + git_branch). Przycisk Commit & Push wypycha HEAD:refs/heads/<branch> prosto na ten zdalny (obsługiwany zarówno GitHub, jak i GitLab, z linkiem do commita w odpowiedzi), a git_push = True sprawia, że dzieje się to automatycznie przy każdym deployu. Błędy gita nigdy nie cofają deployu — pojawiają się w wyniku deployu i w logu audytowym.

Log audytowy

Każdy deploy, git push i zmiana przypisania zespołu/pliku trafia do dopisywalnego logu JSONL, widocznego w UI (wymaga uprawnień do edycji) albo czytelnego wprost z dysku.