• v0.29.1 1b8c346809

    0.29.1 — G1, with the address the PII guard demands
    All checks were successful
    CI / gate (push) Successful in 1m25s
    CI / image (push) Successful in 15s
    Stable

    joeyr released this 2026-08-21 21:38:20 -05:00 | 20 commits to main since this release

    0.29.0's gate went red in CI and never published an image. The tag and the release
    exist; the registry has no 0.29.0, and :latest stayed on 0.28.3, so nothing was
    deployed from it. This is that release with the one thing CI caught.

    Fixed

    • tests/test_gmail.py used realistic @gmail.com addresses, and test_no_pii
      refuses those in a public repo. Now example.com / example.net, which _RESERVED
      already exempts — rather than extending _ALLOWED, since nothing in the file depends on
      the domain, only on the two tenants having different ones.

    Notes

    • The local gate was green, and was green honestly. test_no_pii walks tracked
      files, and tests/test_gmail.py was still untracked when the gate ran — so the file
      under test was invisible to the test that would have caught it. Committing brought it
      into scope, and CI, which checks out the committed tree, saw it immediately.

      That is the check working, not failing: an untracked file is not published, so scanning
      tracked files is right. What was wrong is the habit of gating before staging. Run the
      gate against the staged tree
      when a commit adds files — git stash push --keep-index
      is what that costs.

    • Reproduced in a clean venv built the way CI builds one — --require-hashes from
      requirements-dev.txt, then -e . --no-deps — rather than guessed at from the run
      status. The API exposes no log endpoint and the web log route does not take a token, so
      reproducing locally is the shorter path.

    • 1100 tests green.

    Downloads