Comparing changes

Closes #552. The release job uploaded to PyPI only inside a `workflow_dispatch` run, so a tag created any other way (for example pushed by hand) produced a git tag and a GitHub release but never reached PyPI. 📦 That is exactly how `3.29.2` and `3.29.3` ended up tagged and GitHub-released yet missing from PyPI, which broke downstreams like pkgsrc that fetch distfiles from there. Publishing moves into a new `publish.yaml` triggered on tag push: it builds at the tag and uploads to PyPI with `skip-existing`, then creates the GitHub release if one is absent. The dispatch job now only writes the changelog and pushes the tag, and because it pushes with `RELEASE_TOKEN` (a PAT rather than `GITHUB_TOKEN`) that push triggers `publish.yaml`. The tag becomes the single source of truth for a release, so any tag always reaches PyPI instead of silently skipping it. The canonical way to cut a release is unchanged: run the 🚀 Release workflow with a `patch`/`minor`/`major` bump. The only behavioral change is that the upload happens in the tag-triggered run rather than in the dispatch run itself.

a soft lock file lives in a shared directory that a same-uid or cross-host peer can write, and _parse_lock_holder turns its first line into a pid with int() but never checks the range, unlike _parse_marker_bytes which already rejects anything outside 1..2**31-1. a holder line of 0 or -1 parses fine, so _is_process_alive ends up calling os.kill(0, 0) or os.kill(-1, 0), and those probe the caller's own process group rather than a real holder and report success, so a long-dead lock reads as still held and is never reclaimed. a pid too large for the C pid_t is worse: os.kill raises OverflowError, which is neither OSError nor ValueError, so it slips past the suppress() guard and aborts acquire() instead of letting the malformed lock self-heal. the fix range-checks the parsed pid against the same window the marker parser uses, so an out-of-range value is treated as an unparseable holder and self-heals after the age threshold like any other malformed file. added a regression covering 0, -1 and an oversized pid. --------- Co-authored-by: Bernát Gábor <[email protected]>

The first dispatch release after #557 failed at checkout with `Input required and not supplied: token` (run https://github.com/tox-dev/filelock/actions/runs/27292630778). `RELEASE_TOKEN` is an environment-scoped secret on the `release` environment. #557 moved publishing into `publish.yaml` and, in trimming the tag job down to just commit-changelog-and-push, dropped its `environment: release`. Without selecting the environment the secret resolves empty, so the `actions/checkout` `token` input is blank and the job dies before tagging anything (nothing partial was released). Re-selecting `environment: release` on the tag job restores `RELEASE_TOKEN` access. The environment has no protection rules, so this adds no approval step, and `publish.yaml` already selects the same environment for the PyPI upload.

Follow-up to #557/#559. The first real release on the new flow (3.29.3) tagged and committed the changelog but failed to publish: PyPI trusted publishing is bound to the workflow *filename*, and the project trusts `release.yaml`, so the OIDC token minted from the new `publish.yaml` was rejected with `invalid-publisher`. This folds the publish job back into `release.yaml`, gated on a tag push, and adds a `tags` trigger. The tag job (dispatch only) still prepares the changelog and pushes the tag; that push re-enters this workflow on the tag ref, where the `publish` job uploads to PyPI and creates the GitHub release. Publishing keys off the tag rather than the dispatch event, so a hand-pushed tag still reaches PyPI — but the OIDC claim's `workflow_ref` is now `release.yaml`, matching the registered publisher. `publish.yaml` is removed. The build job's uv cache is disabled because it now builds the artifact that gets published, so a poisoned cache must not be a release vector (zizmor `cache-poisoning`). Recovers the stuck 3.29.3 once merged (re-tag at the fixed commit triggers the publish job).

Navigation Menu

Repository navigation

Comparing changes

Open a pull request

Commits on Jun 10, 2026

This comparison is taking too long to generate.

Uh oh!