You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Feature Request: Airflow to support DAGs Git Sync using SSH Key #382
The addition of SSH connection support for DAG Git Sync is proposed to enhance both the functionality and security of the API. This feature is already supported by the Official Helm Chart, which could serve as a valuable reference for implementation. Incorporating SSH connections would not only streamline the synchronization process but also bolster security measures during the sync operations
Hi @ruslanguns
Thank you for the issue.
We talked internally and think it would be a useful feature.
I have put it on the roadmap but it can be a while before we get to it. I'll update the ticket when we have an update.
You might be able to get it working using config overrides as we believe all settings can be done using environment variables.
This issue has been implemented with CRD versioning for the airflow operator, meaning that this change is non-breaking.
Release notes snippet
Airflow can now use gitsync to authenticate against a repository using SSH keys as well as basic auth, which was previously the only option. The Airflow operator also now has the ability to convert certain changes between CRD versions: in the case of this change, the operator can automatically convert the field credentialsSecret to credentials:basicAuthSecretName so that this change is non-breaking. N.B. conversions in the opposite direction - from v1alpha2 to v1alpha1 - are not possible if the v1alpha2 resource definition refers to the new field.
TODO
Link the release note to the operator docs, and the operator docs (gitsync/ssh secton) to the release notes.
Well, this is one of the very first cases of a breaking change that is mitigated using CRD versioning 😅
So we need to figure out the process here, happy to discuss this!
This change itself technically isn't breaking, but in a few months/years when we remove support for v1alpha1, that will be breaking. And for that the users need to know what the breaking change was and how to mitigate it.
Maybe we should track the list of breaking changes using CRD versioning not in the platform release notes, but per CRD, as they are related to the CRD version, but not the platform version?
Activity
lfrancke commentedon Feb 5, 2024
Hi @ruslanguns
Thank you for the issue.
We talked internally and think it would be a useful feature.
I have put it on the roadmap but it can be a while before we get to it. I'll update the ticket when we have an update.
You might be able to get it working using config overrides as we believe all settings can be done using environment variables.
We haven't tested this though!
adwk67 commentedon Jan 15, 2026
This issue has been implemented with CRD versioning for the airflow operator, meaning that this change is non-breaking.
Release notes snippet
TODO
Link the release note to the operator docs, and the operator docs (gitsync/ssh secton) to the release notes.
lfrancke commentedon Feb 4, 2026
You labeled it
action-required@sbernauer. The release notes don't reflect that. Could one of you clarify?adwk67 commentedon Feb 4, 2026
This should be linked to in the release notes: https://docs.stackable.tech/home/nightly/airflow/usage-guide/mounting-dags/#_via_git_sync
This should be linked to in the operator docs: TODO (when release notes are finished)
sbernauer commentedon Feb 5, 2026
Well, this is one of the very first cases of a breaking change that is mitigated using CRD versioning 😅
So we need to figure out the process here, happy to discuss this!
This change itself technically isn't breaking, but in a few months/years when we remove support for v1alpha1, that will be breaking. And for that the users need to know what the breaking change was and how to mitigate it.
Maybe we should track the list of breaking changes using CRD versioning not in the platform release notes, but per CRD, as they are related to the CRD version, but not the platform version?
lfrancke commentedon Feb 10, 2026
Understood, thank you. I think we can then mark it as breaking again when we remove old versions. For now at least.
sbernauer commentedon Feb 10, 2026
I agree with better safe than sorry and keep the
action-requiredlabel