Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: tox-dev/filelock
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: 3.27.0
Choose a base ref
...
head repository: tox-dev/filelock
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: 3.28.0
Choose a head ref
  • 2 commits
  • 3 files changed
  • 2 contributors

Commits on Apr 14, 2026

  1. 🐛 fix(ci): unbreak release workflow, publish to PyPI again (#529) 

    Releases have been silently broken on PyPI since 3.26.0. Every dispatch
of the release workflow since then produced a
``filelock-X.Y.Z.devN+g<sha>-py3-none-any.whl``, which PyPI rejects with
``400 Bad Request`` because local version identifiers are not allowed on
the public index. 🐛 PyPI still shows 3.25.2 as the latest version while
GitHub has tags and releases for 3.26.0, 3.26.1, and 3.27.0. Anyone
running ``pip install filelock`` is stuck on the last working release.

Commit 8cd6bd9 (``🔒 ci(workflows): add zizmor security auditing #517``)
moved the release version from a GitHub Actions template expression into
a bash environment variable to harden against template injection. The
move was correct, but kept the existing single quotes around the
reference: ``git tag '${STEPS_V_OUTPUTS_VERSION}'``. In bash, single
quotes suppress variable expansion, so ``git tag`` received the literal
28-character string ``${STEPS_V_OUTPUTS_VERSION}`` as the tag name.
hatch-vcs then could not find a real version on ``HEAD``, ``uv build``
fell back to the ``.devN+g<sha>`` scheme, and PyPI rejected the upload.
Double quotes preserve the env-var indirection zizmor wanted while
letting bash actually read the value, so the correct version gets tagged
and the wheel is built with the clean
``filelock-X.Y.Z-py3-none-any.whl`` name PyPI expects.

Why this slipped past CI: the tag-creation step is gated behind ``if:
github.event.inputs.release != 'no'``, so regular push and pull-request
events skip it entirely. The broken line only runs under manual
workflow-dispatch, and even then the failure surfaces in the ``release``
job's PyPI-publish step, which no PR-level check watches. The last two
successful CI builds of the release workflow were the ones that actually
broke publishing.

The second commit aligns the ``actions/upload-artifact`` version
comments with the exact tag the pinned hash resolves to (``v7.0.0``
instead of ``v7``). 🔒 Zizmor flags the mismatch as
``ref-version-mismatch`` because the moving major tag ``v7`` currently
points to a different commit, and pre-commit would otherwise block this
branch on its own audit. The pinned hash does not change, so there is no
behavioral impact.

After merge, re-dispatch the release workflow with a ``patch`` bump (or
whatever bump type makes sense) to get the currently-unpublished work
onto PyPI.
    @gaborbernat
    gaborbernat authored Apr 14, 2026
    Configuration menu
    Copy the full SHA
    476b0e4 View commit details
    Browse the repository at this point in the history

  2. Release 3.28.0

    @gaborbernat
    gaborbernat committed Apr 14, 2026
    Configuration menu
    Copy the full SHA
    55de20c View commit details
    Browse the repository at this point in the history
Loading