[higagan]

Fixes #76.

The problem

On push: tags: v* the dispatch input is empty, so the job ran a bare pip install modelfuzz — PyPI's current latest. There is no publish workflow in this repo, so the tag lands before the upload and the job smoke-tested the previous release and went green. The one version assertion compared two values from the same install, so it could never fail.

This matters now: it's the check that would have been vouching for the 0.4.0 release.

Changes

• Expected version is resolved explicitly — from the dispatch input, else from the tag (v0.4.0 → 0.4.0), else none (then it tests latest, as before).
• Install retries for up to ~5 min while PyPI indexes the new release, instead of silently falling back to the old one.
• Installed version is asserted equal to the expected one. The sdist check is pinned the same way, so it inspects the right release.
• Shell injection closed. ${{ github.event.inputs.version }} was interpolated into run: bash, and command substitution fires even inside a quoted test (0.3.8$(id -un) → modelfuzz==0.3.8gagandeep, confirmed). The value now travels via env: and is validated against a version pattern before use. Needs repo write access to trigger, so low-privilege — but free to fix.
• permissions: contents: read on both workflows (they ran with the repo-default token).
• Third-party actions pinned to commit SHAs (checkout, setup-python, setup-uv), with the tag in a trailing comment.

Verified

I can't run Actions locally, so I tested the shell logic directly:

input	result
tag v0.4.0	expects 0.4.0
branch, no input	expects nothing → tests latest
input 0.3.8, 0.4.0rc1	accepted
input 0.3.8$(id -un)	rejected
input 0.3.8; curl evil.com	rejected
tag v0.4.0-evil	rejected

Both YAML files parse. The retry loop and real PyPI install can only be exercised on the next tag or a manual dispatch — worth a workflow_dispatch run with the current 0.3.9 after merge as a sanity check.

🤖 Generated with Claude Code