coleheflin commented on code in PR #69735:
URL: https://github.com/apache/airflow/pull/69735#discussion_r3753603747
##########
providers/git/docs/bundles/index.rst:
##########
@@ -41,3 +41,25 @@ Example of using the GitDagBundle:
}
}
]'
+
+``tracking_ref`` accepts a branch, tag, or full commit SHA. Setting it to a
commit SHA pins the
+bundle to that exact commit:
+
+.. code-block:: bash
+
+ export AIRFLOW__DAG_PROCESSOR__DAG_BUNDLE_CONFIG_LIST='[
+ {
+ "name": "my-git-repo",
+ "classpath": "airflow.providers.git.bundles.git.GitDagBundle",
+ "kwargs": {
+ "repo_url": "https://github.com/org/repo.git";,
+ "tracking_ref": "a3d1850dd1aa1919a61620aa39f202185c9321c0",
+ "subdir": "dags"
+ }
+ }
+ ]'
+
+Branches move as new commits are pushed, so combined with ``refresh_interval``
they pick up new code
+without a restart. Tags and commit SHAs are static (assuming tags aren't
moved), pinning the bundle
+to known-good code — but promoting or rolling back a SHA means changing
``tracking_ref`` in
+``dag_bundle_config_list`` itself, which requires restarting the Dag processor
to take effect.
Review Comment:
Confirmed the mechanism — traced through
`_initialize`/`_clone_repo_if_required`/`_fetch_bare_repo`/`refresh()`, and
reproduced the failure with a unit test exercising that same code path (real
git subprocess calls against a local temp repo, not a live deployment): moving
the promoted commit's creation to after the first `initialize()` makes the
second `initialize()` raise `GitCommandError: fatal: unable to read tree
(<sha>)` (same failure you found, slightly different git-version wording than
"reference is not a tree"), while rollback to an already-local commit still
succeeds.
Reworded the doc note to say exactly what you suggested — rollback is
reliable, promotion needs the bundle's local storage cleared (fresh pod, or
deleted bundle dir) — and opened https://github.com/apache/airflow/issues/71388
to track the actual fetch-before-checkout fix, linked from both the doc note
and a comment at the `checkout` call in `_initialize`.
---
Drafted-by: Claude Code (Sonnet 5); reviewed by @coleheflin before posting
##########
providers/git/docs/bundles/index.rst:
##########
@@ -41,3 +41,25 @@ Example of using the GitDagBundle:
}
}
]'
+
+``tracking_ref`` accepts a branch, tag, or full commit SHA. Setting it to a
commit SHA pins the
+bundle to that exact commit:
+
+.. code-block:: bash
+
+ export AIRFLOW__DAG_PROCESSOR__DAG_BUNDLE_CONFIG_LIST='[
+ {
+ "name": "my-git-repo",
+ "classpath": "airflow.providers.git.bundles.git.GitDagBundle",
+ "kwargs": {
+ "repo_url": "https://github.com/org/repo.git";,
+ "tracking_ref": "a3d1850dd1aa1919a61620aa39f202185c9321c0",
+ "subdir": "dags"
+ }
+ }
+ ]'
+
+Branches move as new commits are pushed, so combined with ``refresh_interval``
they pick up new code
+without a restart. Tags and commit SHAs are static (assuming tags aren't
moved), pinning the bundle
+to known-good code — but promoting or rolling back a SHA means changing
``tracking_ref`` in
+``dag_bundle_config_list`` itself, which requires restarting the Dag processor
to take effect.
Review Comment:
Good catch, added back. The note now says that with `[dag_processor]
disable_bundle_versioning` (or the per-Dag parameter) set, workers resolve code
from their own `tracking_ref` rather than a recorded bundle version, so they
need the updated config too — not just the Dag processor.
---
Drafted-by: Claude Code (Sonnet 5); reviewed by @coleheflin before posting
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
