Publishing Checklist¶
The workspace uses the standard ci.yml > release.yml >
cd.yml workflow shape. release.yml owns release-please. When a
release-please PR merge creates a release tag, it dispatches cd.yml
with the selected package name. extended-data releases also deploy
the Sphinx/Furo documentation site. Do not hand-edit versions, changelog
entries, release tags, or GitHub releases during the normal release
path.
Release Model¶
release.ymlowns release-please version detection, changelog updates, release PRs, Git tags, and dispatchingcd.ymlafter a release is created.cd.ymlowns tag-gated package verification, selected-package PyPI publication, andextended-datadocs deployment.cd.ymldeploys GitHub Pages only forextended-datareleases.Published package names are
extended-dataandpytest-extended-data.The CD workflow publishes only for the release tag passed by
release.yml.The PyPI job uses OIDC trusted publishing through
uv publish; no PyPI token should be stored in repository secrets for the normal path.PyPI trusted publishers for this repository must use workflow filename
cd.yml.Do not configure package release-please entries to update the root
uv.lockthroughextra-files. The release PR owns package metadata, changelogs, and the release manifest; workspace setup can refresh the lock locally when needed.
Maintainer Preflight¶
Run these before merging a release PR or manually dispatching release workflow diagnostics:
uv sync --all-packages --all-extras --dev
tox -e lint,typecheck,audit,py311,py312,py313,py314,examples,docs,build
Workflow Hygiene¶
Keep
.github/workflows/*.ymlactions pinned to exact commit SHAs.Update adjacent version comments when refreshing action SHAs.
Use
ghto verify latest stable action releases before changing pins.Keep top-level
permissions: {}and grant only job-scoped permissions.
Current workflow action pins:
Action |
Stable version |
Commit SHA |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Publishing Flow¶
Land normal feature, fix, docs, and maintenance commits using Conventional Commit prefixes.
Let
release.ymlopen or update the release-please PR.Review the release PR for the expected changelog and manifest updates.
Merge the release PR.
Confirm
release.ymlcreated the GitHub release and dispatched the expected package CD workflow.Confirm the package CD workflow published to PyPI through trusted publishing.
For
extended-datareleases, confirmcd.ymldeployed the Sphinx site to GitHub Pages forextended-data.dev.Verify the package can be installed from PyPI:
python -m pip install extended-data
python -c "import extended_data; print(extended_data.__version__)"
python -m pip install pytest-extended-data
python -c "import pytest_extended_data; print(pytest_extended_data.__all__)"
Manual Repairs¶
Manual tags or PyPI uploads are repair paths, not the release process. If a release workflow fails after release-please creates a tag:
Keep the failed tag intact while diagnosing unless the release is proven unrecoverable.
Prefer rerunning the failed workflow job.
If a bad GitHub release was published, delete only the bad artifacts needed for repair.
Document the repair in the PR or release notes.
First pytest-extended-data Publish¶
PyPI does not let a trusted publisher create a brand-new project unless
there is a matching pending publisher. Before rerunning the first
pytest-extended-data CD publish, add this pending publisher in PyPI:
Field |
Value |
|---|---|
PyPI project |
|
GitHub owner |
|
GitHub repository |
|
Workflow filename |
|
Environment |
leave blank |
Then rerun:
gh workflow run cd.yml --ref main -f tag=pytest-extended-data-v0.1.0 -f package=pytest-extended-data