A typical release cycle goes like this: someone pushes a patch to Gerrit, CI fires, and then a human waits for approvals in Airflow that only work when the right branch merges. It sounds simple until you realize half your team is stuck toggling permissions instead of building.
Airflow runs your DAGs, schedules, and dependencies. Gerrit handles review, access control, and change tracking. Bring them together and you get a closed loop: code change to deployment with traceable approvals along the way. The Airflow Gerrit integration lets you review, trigger, and audit pipelines automatically based on repository state.
At its core, the flow is straightforward. Gerrit emits change events over its stream API. Airflow listens, either through a lightweight sensor or a custom operator. When a patchset lands, Airflow triggers the corresponding DAG, runs the tests, then reports the build back to Gerrit as a verified vote or status update. The result is tighter governance with less human glue code.
To make it secure, map identities through your existing provider. Gerrit already ties to LDAP or OIDC, and Airflow supports the same. Use those shared groups to define who can trigger or approve DAGs. If you rely on Okta or AWS IAM, issue scoped tokens instead of broad SSH access. The goal is one consistent identity layer that maintains RBAC parity across systems.
A quick rule of thumb: permissions should flow downstream, never upstream. Gerrit reviewers should not mutate DAG definitions, and Airflow service accounts should not push code back. Isolate these in configuration, not just policy documents. Platforms like hoop.dev turn those access rules into guardrails that enforce policy automatically, so your developers can focus on workflows, not credentials.