Add GitHub App authentication for git DAG bundles

[RaphCodec]

Purpose

Adding GitHub App Authentication to the Git Provider. This feature is intended to be a security benefit for those who want to use GitHub Dag Bundles in Airflow 3, but for whatever reason cannot use a SSH deploy key to authenticate to GitHub and would prefer not to use their own PAT.

---

In case of an existing issue, reference it using one of the following:

• closes: Git Provider GitHub App Authentication #62478

---

Was generative AI tooling used to co-author this PR?

• Yes - Claude Sonnet 4.6

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

---

Important

🛠️ Maintainer triage note for @RaphCodec · by @potiuk · 2026-06-22 06:31 UTC

Helpful heads-up from the maintainers — please address before this PR can be reviewed (see the Pull Request quality criteria):

• ❌ Tests — failing: provider distributions tests / Compat 3.0.6:P3.10:, provider distributions tests / Compat 3.1.8:P3.10:, provider distributions tests / Compat 3.2.2:P3.10:.

The ball is in your court — you've been assigned to this PR. Fix the above, then mark it Ready for review.

_{Automated triage — may be imperfect; a maintainer takes the next look.}

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide (https://github.com/apache/airflow/blob/main/contributing-docs/README.rst)
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example DAG that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
• Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack

[potiuk]

@RaphCodec Converting to draft — this PR doesn't yet meet our Pull Request quality criteria.

• ❌ Merge conflicts: This PR has merge conflicts with the main branch. Your branch is 90 commits behind main. Please rebase your branch (git fetch origin && git rebase origin/main), resolve the conflicts, and push again. See contributing quick start.

Note: Your branch is 90 commits behind main. Please rebase and push again to get up-to-date CI results.

See the linked criteria for how to fix each item, then mark the PR "Ready for review". This is not a rejection — just an invitation to bring the PR up to standard. No rush.

---

Note: This comment was drafted by an AI-assisted triage tool and may contain mistakes. Once you have addressed the points above, an Apache Airflow maintainer — a real person — will take the next look at your PR. We use this two-stage triage process so that our maintainers' limited time is spent where it matters most: the conversation with you.

[Copilot]

Pull request overview

Adds GitHub App-based authentication support to the Git provider’s GitHook so Git-backed DagBundles can authenticate to GitHub without SSH deploy keys (using an installation access token instead).

Changes:

• Extend GitHook connection extras/UI placeholders to accept GitHub App identifiers and generate an installation token for HTTPS cloning.
• Add an optional dependency extra for GitHub App support (pygithub / PyGithub) in the git provider.
• Update the workspace lockfile to include the new optional extra and reflect a refreshed dependency resolution.

Reviewed changes

Copilot reviewed 2 out of 3 changed files in this pull request and generated 6 comments.

File	Description
providers/git/src/airflow/providers/git/hooks/git.py	Adds GitHub App auth fields and token generation logic to rewrite HTTPS repo URLs with an installation token.
providers/git/pyproject.toml	Introduces an optional dependency extra for GitHub App support.
uv.lock	Updates the lockfile to include the new optional extra and updated resolved packages.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 4 changed files in this pull request and generated 2 comments.

[RaphCodec]

Thanks for the feedback. I went over the code more thourghly, improved it and updated the branch. I will try to update the branch at least once a day to prevent merge conflicts.

[potiuk]

@RaphCodec Converting to draft — this PR doesn't yet meet our Pull Request quality criteria.

• ❌ Merge conflicts: This PR has merge conflicts with main. GitHub's "Update branch" button cannot resolve them — please rebase locally and resolve the conflicts manually:

  git fetch upstream main
  git rebase upstream/main
  # resolve conflicts, then:
  git push --force-with-lease
  

• ❌ Failing CI checks: Failing: Build info. This is most likely a downstream effect of the merge conflicts above — once the rebase is clean, please re-trigger CI by pushing the rebased branch.

See the linked criteria for how to fix each item, then mark the PR "Ready for review". This is not a rejection — just an invitation to bring the PR up to standard. No rush.

---

Note: This comment was drafted by an AI-assisted triage tool and may contain mistakes. Once you have addressed the points above, an Apache Airflow maintainer — a real person — will take the next look at your PR. We use this two-stage triage process so that our maintainers' limited time is spent where it matters most: the conversation with you.

[potiuk]

requesting changes.

[potiuk]

Second-read pass via Codex (adversarial review). Independent of the primary review above; both reads converge on the token-lifecycle concern.

Codex Adversarial Review

Target: branch diff against main
Verdict: needs-attention

No-ship: the GitHub App auth path can leak installation tokens over plain HTTP and appears to persist one-hour tokens into Git remotes without a refresh path.

Findings:

• [high] GitHub App tokens are allowed in plain HTTP repository URLs (providers/git/src/airflow/providers/git/hooks/git.py:159-162)
  GitHub App auth is documented here as requiring an HTTPS repository URL, but the guard accepts both https:// and http://. _process_git_auth_url() then embeds the generated installation token into the URL, so a misconfigured http://github.com/... or enterprise URL can put a live installation token on a plaintext request or redirect path. This is a credential exposure risk introduced by this auth mode.
  Recommendation: Reject anything except https:// when GitHub App auth is enabled; do not permit http:// for generated installation tokens.
• [high] Installation token is generated once and persisted into Git remotes (providers/git/src/airflow/providers/git/hooks/git.py:167-171)
  The hook fetches a GitHub App installation token during __init__, stores it as auth_token, and then rewrites repo_url with that token. Inference from GitDagBundle: the first clone stores this URL as the bare repository's origin, and later refresh/fetch operations use the existing remote rather than rebuilding credentials. GitHub installation tokens expire, so long-lived Dag bundle directories can start failing fetches after token expiry even though the app key is still valid.
  Recommendation: Do not persist installation tokens in the remote URL. Refresh the token immediately before each network operation and pass it through a non-persistent credential mechanism, or update the remote URL with a fresh token before every fetch/clone and scrub it afterward.

[potiuk]

@RaphCodec Converting to draft — this PR doesn't yet meet our Pull Request quality criteria.

• ❌ Provider tests — Failing: provider distributions tests / Compat 3.0.6:P3.10:, provider distributions tests / Compat 3.2.1:P3.10:, provider distributions tests / Compat 3.1.8:P3.10:, Low dep tests: providers / All-prov:LowestDeps:14:3.10:exasol...microsoft.win, Non-DB tests: providers / Non-DB-prov::3.10:-amazon,celer...standard (+2 more). See docs.
• ❌ Other failing CI checks — Failing: Additional PROD image tests / Test e2e integration tests with PROD image / Regular e2e test. See docs.

See the linked criteria for how to fix each item, then mark the PR "Ready for review". This is not a rejection — just an invitation to bring the PR up to standard. No rush.

---

Note: This comment was drafted by an AI-assisted triage tool and may contain mistakes. Once you have addressed the points above, an Apache Airflow maintainer — a real person — will take the next look at your PR. We use this two-stage triage process so that our maintainers' limited time is spent where it matters most: the conversation with you.

---

Drafted-by: Claude Code (Opus 4.7); reviewed by @potiuk before posting

[RaphCodec]

@potiuk sorry about that I meant to convert this to a draft after you requested changes. I'm working on adding the changes and will mark for review after.

Thanks for the feedback.

[RaphCodec]

@potiuk I made the requested changes and address issues 1-9.

[jscheffl]

I am not an expert of GH App Auth, so I can just skim over the code. Does not look bad but I can not really judge. Some other maintainer around who known more?

[RaphCodec]

@potiuk I checked the failing provider distribution tests and they seem to be unrelated to the changes in my PR. The failing tests (https://github.com/RaphCodec/airflow/actions/runs/28319050045/job/83900082499) failed due to issues with the amazon and azure providers.

Example Error:

================================================================================================= ERRORS =================================================================================================
_______________________________________________________ ERROR collecting providers/microsoft/azure/tests/unit/microsoft/azure/hooks/test_batch.py ________________________________________________________
ImportError while importing test module '/opt/airflow/providers/microsoft/azure/tests/unit/microsoft/azure/hooks/test_batch.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/python/lib/python3.10/importlib/__init__.py:126: in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
providers/microsoft/azure/tests/unit/microsoft/azure/hooks/test_batch.py:24: in <module>
    from azure.batch import BatchServiceClient, models as batch_models
E   ImportError: cannot import name 'BatchServiceClient' from 'azure.batch' (/usr/python/lib/python3.10/site-packages/azure/batch/__init__.py)
_____________________________________________________ ERROR collecting providers/microsoft/azure/tests/unit/microsoft/azure/operators/test_batch.py ______________________________________________________
ImportError while importing test module '/opt/airflow/providers/microsoft/azure/tests/unit/microsoft/azure/operators/test_batch.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:

I'm not sure how those would be resolved in this PR as they are unrelated so I'd like to mark this PR for review. If you believe this is related to my PR please let me know and I'll look into this further.

I ran all the static checks locally and they passed, and the CI images all built successfully.

[RaphCodec]

@potiuk I reviewed the provider distributions tests / Compat test logs from this PR. A lot of the errors look to be import errors or a faillure to git remote add apache-https-for-providers . I've tried to debug the errors and followed the guide to test compatibility.

I have not been able to resolve the failing tests, yet. However, it doesn't appear that the code in my PR is causing the errors as, so I'm marking this for review.

I know that the Compat tests should pass to be in line with the PR quality standards, but I am not sure why the Compat tests are having import issues. If there is something that I am missing I'd be happy to fix it. I'll keep looking for a solution.