Going from clean clone to a published v0.1.0 in roughly an hour.
- Git repo on
main, working tree clean. - A version source the tooling can read (
pyproject.toml,package.json,Cargo.toml,pom.xml, or git tag). pip install simtabi-release-kit.
release-kit initThis writes release.json and .env-example to the current
directory and appends .env to .gitignore.
Set the project name and add the targets you want. A minimal example for a Python package going to PyPI + GHCR + GitHub Releases:
{
"project": {
"name": "my-package",
"version_source": "pyproject.toml"
},
"targets": {
"pypi": { "enabled": true, "auth": "oidc", "package": "my-package" },
"ghcr": { "enabled": true, "auth": "oidc", "image": "ghcr.io/my-org/my-package", "tags": ["0.1.0", "latest"] },
"github": { "enabled": true, "auth": "token", "repo": "my-org/my-package", "tag": "v0.1.0", "topics": ["python"] }
},
"policies": {
"require_clean_git": true,
"require_tag_match": true,
"default_dry_run": true
}
}- PyPI: register the project name and add a trusted publisher
pointing at your GitHub repo + workflow file.
See
playbook/registries/pypi.md. - GHCR: nothing to do; the GHCR token from the workflow's
GITHUB_TOKENis enough. - GitHub releases: create a fine-grained PAT scoped to the
repo with
Contents: Write; export asGITHUB_TOKENlocally or store viarelease-kit rotate-tokens --platform github.
release-kit doctorEvery target should show GREEN. AMBER is acceptable for warnings (e.g. a topics list left empty). RED blocks the publish.
git tag v0.1.0
git push origin v0.1.0release-kit publishRead the report. Every step should be dry-run (cyan).
release-kit publish --applyFor real. The report turns green; new versions appear on the registries; the GitHub Release object is created.
release-kit publish --apply | tee publish.log
release-kit doctor # quick re-check; tag URL is now liveFor Python:
pipx run --pip-args="--no-cache-dir" my-package==0.1.0 --versionSee ci-release.md.