lyrathorpeandEmma Thorpe
e2ec48f1db
## The defect `pyproject.toml` carried a static version while releases are derived from conventional commits and tagged by CI. The first release after the packaging change was cut as **v0.4.0** while the file still declared `0.3.0`, so both the Python package metadata and the Nix store path understated the release. ## Why a human cannot fix this by hand The version is computed from commit messages *since the last tag* and is only known inside the release job, after the build. The pull request that causes a release cannot know the number it will produce — especially with more than one PR in flight. Any hand-set value drifts again at the next release. ## The fix The release job now writes the computed version into `pyproject.toml`, commits it as `chore(release): vX.Y.Z`, and tags **that** commit. - Neither push re-triggers the workflow: it listens on `main` only for the image-affecting paths, and `pyproject.toml` is not one of them. - `chore(release)` produces no bump of its own on the next run. - The branch push is ordered before the tag push, so a rejected push (main moved on) cannot leave a tag pointing at a commit that is not on `main`. - `pyproject.toml` is bumped to `0.4.0` here to correct today's state; from the next release onward CI maintains it, and a comment in the file says so. ## Verification - The version-rewrite step was extracted from the workflow and run against a copy of `pyproject.toml`: the line is rewritten, and the step raises if it ever finds no version line rather than silently doing nothing. - `bash -n` on the step, `nix flake check` green at 0.4.0. - `main` has no branch protection rules, so the job's push will be accepted. If you ever add protection, the CI token needs an exemption or this step fails. --------- Co-authored-by: Emma Thorpe <emma.thorpe@citrix.com> Reviewed-on: #17
29 lines
927 B
TOML
29 lines
927 B
TOML
[build-system]
|
|
requires = ["setuptools>=77"]
|
|
build-backend = "setuptools.build_meta"
|
|
|
|
[project]
|
|
name = "legacy-email-proxy"
|
|
# Written by the release job in .gitea/workflows/build-and-publish.yaml, which
|
|
# derives the version from conventional commits and tags the result. Do not
|
|
# edit by hand: a hand-set value is overwritten at the next release.
|
|
version = "0.4.0"
|
|
description = "Unauthenticated POP3/SMTP front end proxied to authenticated IMAPS/SMTPS backends"
|
|
readme = "README.md"
|
|
requires-python = ">=3.12"
|
|
dynamic = ["dependencies"]
|
|
|
|
[project.scripts]
|
|
legacy-email-proxy = "proxy_server:run"
|
|
|
|
[project.urls]
|
|
Homepage = "https://code.emmathe.dev/lyrathorpe/legacy-email-proxy"
|
|
|
|
# requirements.txt stays the single source of runtime dependencies, so the
|
|
# Dockerfile and this file cannot drift apart.
|
|
[tool.setuptools.dynamic]
|
|
dependencies = { file = ["requirements.txt"] }
|
|
|
|
[tool.setuptools]
|
|
py-modules = ["proxy_server"]
|