Summary
Foreman is currently distributed only from source. Publish it to the PyPI (https://pypi.org/) registry as foreman-orchestrator so users can pip install foreman-orchestrator (or uv tool
install foreman-orchestrator) instead of cloning the repo. This issue tracks the full release automation: a versioning rule, a publish pipeline, dependency automation, auto-publish on
version bump, and live status/coverage badges.
Motivation
- One-command install (pip / uv / pipx) lowers the barrier to trying Foreman.
- Tagged, reproducible releases instead of "install from main."
- Trusted, automated publishing removes manual twine upload steps and long-lived API tokens.
Scope
- Versioning rule
- Adopt Semantic Versioning (https://semver.org/) (MAJOR.MINOR.PATCH) as the project rule, documented in CONTRIBUTING.md / CHANGELOG.md.
- Single source of truth for the version — keep pyproject.toml version authoritative (or move to hatch-vcs / git-tag-derived versioning) so the README badge, changelog, and package
metadata never drift.
- Define the bump policy: breaking pipeline/CLI changes → MAJOR, new features → MINOR, fixes → PATCH. Pre-1.0 caveats noted.
- Every release entry recorded in CHANGELOG.md (Keep a Changelog format).
- Publish CI/CD
- Add .github/workflows/ (none exist today) with a build + publish workflow.
- Build sdist + wheel with hatchling, validate with twine check, and publish via PyPI Trusted Publishing (OIDC) (https://docs.pypi.org/trusted-publishers/) — no stored API token.
- Publish to TestPyPI first (on pre-release tags or manual workflow_dispatch) to verify the package before hitting prod PyPI.
- Gate publish on the test suite passing.
- Dependabot
- Add .github/dependabot.yml to keep dependencies current:
- pip ecosystem for pyproject.toml (runtime + dev extras).
- github-actions ecosystem to keep workflow action versions pinned and updated.
- Weekly schedule, grouped minor/patch PRs to reduce noise.
- Auto-publish on version bump
- Trigger the publish workflow automatically when the version changes.
- Two acceptable mechanisms (pick one):
- Tag-driven: pushing a vX.Y.Z git tag builds and publishes; CI asserts the tag matches pyproject.toml.
- Bump-driven: a merge to main that changes version in pyproject.toml creates the tag + GitHub Release, then publishes.
- Create a GitHub Release with auto-generated notes from the changelog as part of the same flow.
- Test badges + coverage badges
- Wire Codecov (https://about.codecov.io/) (or Coveralls) into CI; upload coverage from the pytest run.
- Replace/augment the current static README badges with live ones:
- CI / test-suite status (GitHub Actions workflow badge).
- Coverage % (Codecov badge).
- PyPI version + Python versions + monthly downloads (img.shields.io/pypi/...).
Acceptance criteria
Summary
Foreman is currently distributed only from source. Publish it to the PyPI (https://pypi.org/) registry as foreman-orchestrator so users can pip install foreman-orchestrator (or uv tool
install foreman-orchestrator) instead of cloning the repo. This issue tracks the full release automation: a versioning rule, a publish pipeline, dependency automation, auto-publish on
version bump, and live status/coverage badges.
Motivation
Scope
metadata never drift.
Acceptance criteria