Skip to content

build: derive package versions from Git - #66

Merged
PsiACE merged 3 commits into
mainfrom
build-vcs-version
Oct 7, 2026
Merged

PsiACE merged 3 commits into
mainfrom
build-vcs-version

Conversation

@PsiACE

@PsiACE PsiACE commented Oct 7, 2026 •

Copy link
Copy Markdown
Member

Purpose

Derive release and development versions with hatch-vcs, including GitHub Action archives. Carry versions into containers, include bundled skills in images, and remove release pins from usage examples.

Validation

127 tests passed for the package changes; 21 affected behavior tests passed for archive support. Type checking, pre-commit, strict docs and package builds pass. Verified tagged and development archives, cache refresh, Compose image CLI/HTTP versions and container skill loading.

Compatibility

Examples use Action main, image latest and the latest PyPI release. Fixed tags and digests remain supported. Source copies without version metadata use 0.0.0.

AI assistance

Implemented with Codex.

@github-actions github-actions Bot left a comment

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.

No blocking findings.

One non-blocking observation: the runtime installed by the Action reports 0.0.0. The runner delivers a remote action as an archive of the repository (GITHUB_ACTION_PATH), so the install step in action.yml has no Git metadata; the new hatch-vcs source falls back to fallback-version, and landing --version and the OpenAPI version field therefore report 0.0.0 for every uses: bubbuild/landing@<ref> run, including refs pinned to a release tag. Reproduced by installing that same archive (gh api repos/bubbuild/landing/tarball/build-vcs-version, extract, uv pip install <dir>), which succeeds but yields 0.0.0; before this change that path reported the released version. Nothing in the Action's inputs, outputs, comments or queue depends on the value, so the effect is limited to someone checking the runtime version while debugging; if you want it to identify the revision, the install step would need to supply SETUPTOOLS_SCM_PRETEND_VERSION itself, since the archive carries no version metadata.

@github-actions github-actions Bot left a comment

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.

No blocking findings.

The version derivation holds on the paths this PR changes: a GitHub source archive of 2b7a6f8 builds as 0.2.1.dev17+g2b7a6f8, so an Action run reports the revision instead of 0.0.0, and a git install from the branch reports 0.2.1.dev17+g2b7a6f8a1. One documented local-build path still reports 0.0.0; details in the inline comment on compose.yaml.

Comment thread compose.yaml

@github-actions github-actions Bot left a comment

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.

No blocking findings.

@PsiACE
PsiACE merged commit c01cd42 into main Oct 7, 2026
10 checks passed
@PsiACE
PsiACE deleted the build-vcs-version branch October 7, 2026 12:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant