Skip to content

ci: switch dynamic versioning from file-based to git tag-based #175

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Aaron ("AJ") Steers (aaronsteers) merged 1 commit into from
Jun 23, 2026
Merged

ci: switch dynamic versioning from file-based to git tag-based #175

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions .github/workflows/publish.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -24,6 +24,7 @@ jobs:
uses: actions/checkout@v7
with:
ref: ${{ github.event.release.tag_name }}
fetch-depth: 0

- name: Install uv
uses: astral-sh/setup-uv@v7
Expand Down
6 changes: 3 additions & 3 deletions pyproject.toml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -31,9 +31,9 @@ build-backend = "hatchling.build"
source = "uv-dynamic-versioning"

[tool.uv-dynamic-versioning]
[tool.uv-dynamic-versioning.from-file]
source = "src/airbyte_api/_version.py"
pattern = "__version__: str = \"(?P<version>[^\"]+)\""
vcs = "git"
style = "pep440"
fallback-version = "0.0.0"
Comment on lines +34 to +36

@devin-ai-integration devin-ai-integration Bot Jun 23, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔴 VCS versioning switch breaks pre-release workflow which still sets version via _version.py sed

The versioning source changed from file-based (from-file reading _version.py) to VCS-based (vcs = "git"), but the pre-release workflow (.github/workflows/pre-release-command.yml:122-127) still uses sed to modify _version.py to set the desired pre-release version. Since uv-dynamic-versioning now derives the package version from git tags instead of _version.py, the sed edit has no effect on the built package version.

Additionally, the pre-release workflow does a shallow checkout (no fetch-depth: 0 at .github/workflows/pre-release-command.yml:113-116), so VCS versioning will fall back to 0.0.0. Even with fetch-depth: 0, the version would be derived from the latest existing tag rather than the user-specified pre-release version, because the pre-release tag is only created after the build/publish steps (.github/workflows/pre-release-command.yml:138-144). The result is that pre-release packages will be published with the wrong version (likely 0.0.0).

Prompt for agents 
The switch from file-based versioning to VCS git-tag-based versioning in pyproject.toml breaks the pre-release workflow at .github/workflows/pre-release-command.yml.

The pre-release workflow (lines 122-130) sets the version by editing src/airbyte_api/_version.py via sed, then builds. Previously, uv-dynamic-versioning read the version from that file, so this worked. Now that versioning is VCS-based (vcs = git), the sed edit is ignored — the package version comes from git tags.

Further, the pre-release workflow does a shallow checkout (no fetch-depth: 0) at line 113-116, so git tag history is unavailable and the version falls back to 0.0.0. Even adding fetch-depth: 0 won't fix it because the pre-release git tag is only created AFTER the build/publish at lines 138-144.

To fix this, the pre-release workflow needs a different mechanism to override the package version for pre-release builds. Possible approaches:
1. Create and push the git tag BEFORE the build step so VCS versioning picks it up (requires reordering steps and adding fetch-depth: 0).
2. Use an environment variable or CLI flag to override the version at build time if uv-dynamic-versioning supports it.
3. Keep the file-based override as a fallback — e.g. set a SETUPTOOLS_SCM_PRETEND_VERSION or equivalent env var that uv-dynamic-versioning respects.
Open in Devin Review

Was this helpful? React with 👍 or 👎 to provide feedback.

@devin-ai-integration devin-ai-integration Bot Jun 23, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚩 fallback-version of 0.0.0 could silently produce bad releases

The fallback-version = "0.0.0" at pyproject.toml:36 means that if VCS versioning fails for any reason (no tags found, shallow clone, detached HEAD without tag info, etc.), the package silently builds as version 0.0.0 instead of failing. This could lead to accidentally publishing a 0.0.0 package to PyPI. Consider whether it would be safer to omit the fallback (so the build fails loudly) or use a clearly-invalid fallback that would be caught by PyPI upload validation. This is a design tradeoff rather than a clear bug.

Open in Devin Review

Was this helpful? React with 👍 or 👎 to provide feedback.

Comment on lines 33 to +36

[tool.hatch.build.targets.sdist]
include = ["src/airbyte_api", "py.typed", "README-PYPI.md"]
Expand Down