6 Commits

Include renames

Author	SHA1	Message	Date
lyrathorpeandEmma Thorpe	efa76ce17b	fix: do not fail the release when pyproject.toml is already current (#18) ... ## The defect The release step added in #17 commits the computed version unconditionally: ```sh git add pyproject.toml git commit -m "chore(release): v${VERSION}" ``` If `pyproject.toml` already carries that version — a re-run of a release, or a version corrected by hand — nothing is staged, `git commit` exits non-zero, and `set -euo pipefail` fails the job. By that point the image has already been pushed, so the release is half-done: published container, no tag. The next run then computes the same version again from the same commits. ## The fix Skip the commit and its branch push when there is nothing staged; tag either way. ## Verification The step was extracted from the workflow and run against a scratch repository with a real `origin`: - `VERSION` equal to the file's version → logs `pyproject.toml is already at 0.1.0`, pushes the tag, no commit. - `VERSION` different → commits `chore(release): v0.2.0`, pushes the branch, then the tag. Both paths leave `main` and the tags consistent. `bash -n` clean. Found while porting this same release scheme to `music-mirror`, which carries the guarded version from the start. --------- Co-authored-by: Emma Thorpe <emma.thorpe@citrix.com> Reviewed-on: #18	2026-08-21 14:50:08 +01:00
lyrathorpeandEmma Thorpe	e2ec48f1db	fix: keep the packaged version in step with the release tag (#17) ... ## 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	2026-08-21 13:50:31 +01:00
lyrathorpe	4ab12f8ce6	Cache pip before install and fix cache key expansion (#12) ... Moves the actions/cache step ahead of the install step and uses the runner.os Actions expression in the cache key. Closes #8 Reviewed-on: #12 Co-authored-by: Lyra Thorpe <iam@emmathe.dev> Co-committed-by: Lyra Thorpe <iam@emmathe.dev>	2026-06-17 17:33:37 +01:00
lyrathorpe	e05f08995e	chore: separate runtime and dev dependencies, add pytest config and CI cache	2026-06-17 16:40:39 +01:00
lyrathorpe	aa746b780d	test: add pytest coverage and run tests in CI	2026-06-17 16:14:22 +01:00
lyrathorpe	739280f930	fix: correct workflow path filter for proxy_server.py	2026-06-17 16:12:39 +01:00