Document commit SHA support for GitDagBundle tracking_ref#69735
Open
coleheflin wants to merge 7 commits into
Open
Document commit SHA support for GitDagBundle tracking_ref#69735coleheflin wants to merge 7 commits into
coleheflin wants to merge 7 commits into
Conversation
GitDagBundle.tracking_ref already works with a full commit SHA in practice (checkout, promote, and rollback), but the provider docs only described it as a branch or tag. Clarify the docstring and provider docs, add a commit-SHA example, note static-ref refresh behavior, and add test coverage for SHA-pinned tracking_ref. Co-Authored-By: Otto <noreply@astronomer.io>
Unlike moving a branch or tag ref, repointing tracking_ref to a new commit SHA is a dag_bundle_config_list config change, so it only takes effect after the Dag processor and workers are restarted to reload the configuration. Co-Authored-By: Otto <noreply@astronomer.io>
Clarify that promoting/rolling back a SHA-pinned tracking_ref (an environment-level config change) is a different mechanism from Dag bundle versioning, which lets individual runs be rerun with their original commit regardless of the bundle's current tracking_ref. Co-Authored-By: Otto <noreply@astronomer.io>
The promote/rollback test already exercises basic SHA checkout as its first step, so the standalone test was redundant. Also tighten the docs note down to two paragraphs without dropping any of the facts. Co-Authored-By: Otto <noreply@astronomer.io>
The rerun_with_latest_version distinction is a separate feature and isn't needed to document tracking_ref's SHA support; keep the note focused on the restart caveat. Co-Authored-By: Otto <noreply@astronomer.io>
…otion The doc previously said promoting or rolling back a SHA-pinned tracking_ref requires restarting both the Dag processor and workers, but only the Dag processor needs to be restarted to pick up the change. Co-Authored-By: Otto <noreply@astronomer.io>
coleheflin
marked this pull request as ready for review
July 13, 2026 16:42
RNHTTR
approved these changes
Jul 13, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Clarifies that
GitDagBundle.tracking_refsupports a branch, tag, or full commit SHA — it already works with a SHA in practice, but the provider docs only described branch/tag. Adds a commit-SHA example to the bundle docs, a note on static-ref refresh behavior (a SHA-pinned bundle doesn't pick up new commits viarefresh_interval; promoting/rolling back requires updatingtracking_refin the bundle config), and test coverage for SHA checkout, promotion, and rollback.Verified manually against a live repository: setting
tracking_refto a full commit SHA checks out that exact commit, promotes to a new SHA when the bundle config is updated, and rolls back when reverted to the prior SHA. The added tests cover the same scenarios. Note that (unlike moving a branch/tag ref) changing a pinned SHA is adag_bundle_config_listconfig change, so it requires restarting the Dag processor and workers to take effect.Was generative AI tooling used to co-author this PR?
Generated-by: Otto following the guidelines
🤖 Generated by Otto