You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Replaces the two-workflow / two-trigger setup (tick "pre-release" =>
TestPyPI; tick "latest" => PyPI) with a single tag-triggered workflow
that runs three sequenced jobs: build, publish-testpypi, publish-pypi.
TestPyPI failure hard-blocks PyPI via `needs:`. The `pypi` environment
gates the final upload behind manual approval.
This matches TabPFN's release pipeline shape, which is the conventional
"standard" pattern for Python releases (also used by numpy, scikit-learn,
etc. in some form). Trade-off: less inspection between TestPyPI and
PyPI, but tighter coupling and only one human click per release.
Other adjustments:
- Tag/version guard: a Python step in the build job verifies that the
pushed tag matches `[project].version` in pyproject.toml. Catches
manual `git tag` typos before the build runs. Becomes a no-op once
hatch-vcs lands (the version derives from the tag, can't mismatch).
- Auto-create GitHub Release: extracts the matching `## [VERSION]`
section from CHANGELOG.md, uploads as artifact, then `gh release
create` runs after PyPI publish. The maintainer never visits the
Releases UI; the release page appears automatically with notes.
- Build runs once. Both publish jobs download the same `dist/`
artifact, guaranteeing identical bytes go to TestPyPI and PyPI.
Action versions kept SHA-pinned per the convention in pull_request.yml.
upload/download-artifact bumped to v7/v8 to match TabPFN's release
pipeline.
Drops publish-test.yml entirely.
0 commit comments