repomatic implements most of the practices described in Astral's Open Source Security at Astral post, baked into a drop-in setup that any maintainer can inherit by pointing their workflows at the reusable callers.
| Astral practice | How repomatic covers it |
|---|---|
Ban dangerous triggers (pull_request_target, workflow_run) |
The lint-workflow-security job runs zizmor on every push: see .github/workflows/lint.yaml |
| Minimal workflow permissions | check_workflow_permissions parses every workflow file and warns when a custom-step workflow omits the top-level permissions key |
| Pinned actions | All uses: refs pinned to full commit SHAs (with the semver tag preserved as a trailing comment) via Renovate's helpers:pinGitHubActionDigestsToSemver preset: see renovate.json5 |
No force-pushes to main |
check_branch_ruleset_on_default verifies an active branch ruleset exists, and the setup guide walks users through creating one |
| Immutable release tags | check_immutable_releases verifies GitHub immutable releases is enabled, and the release workflow rewrites @main refs to @vX.Y.Z during freeze: see tagged workflow URLs |
| Dependency cooldowns | Renovate stabilization windows (minimumReleaseAge) and uv --exclude-newer, with a per-package escape hatch for CVE fixes: see renovate.json5 and Renovate cooldowns |
| Trusted Publishing | PyPI uploads via uv publish with no long-lived token: see the publish-pypi job in .github/workflows/release.yaml |
| Cryptographic attestations | Every binary and wheel is attested to the workflow run that built it via attest-build-provenance: see the Generate build attestations steps in .github/workflows/release.yaml |
| Checksums in installer scripts | The update-checksums CLI command regenerates SHA-256 checksums on every release, invoked from .github/workflows/renovate.yaml when upstream action versions change |
| Fork PR approval policy | check_fork_pr_approval_policy warns when the policy is weaker than first_time_contributors, and the setup guide ships a pre-filled gh api one-liner to fix it |
Warning
Known gap: multi-person release approval. Astral gates releases behind a dedicated GitHub deployment environment with required reviewers, so that a single compromised account cannot publish. repomatic does not enforce this, but if the repository has multiple maintainers, I recommend adding an environment: release key to the publish-pypi and create-release jobs in a downstream caller workflow and configuring required reviewers on that environment in repo settings.
Several workflows need a REPOMATIC_PAT secret to create PRs that modify files in .github/workflows/ and to trigger downstream workflows. Without it, those jobs silently fall back to the default GITHUB_TOKEN, which lacks the required permissions.
After your first push, the setup-guide job automatically opens an issue with step-by-step instructions to create and configure the token.
All workflows use a concurrency directive to prevent redundant runs and save CI resources. When a new commit is pushed, any in-progress workflow runs for the same branch or PR are automatically cancelled.
Workflows are grouped by:
- Pull requests:
{workflow-name}-{pr-number}— Multiple commits to the same PR cancel previous runs - Branch pushes:
{workflow-name}-{branch-ref}— Multiple pushes to the same branch cancel previous runs
release.yaml uses a stronger protection: release commits get a unique concurrency group based on the commit SHA, so they can never be cancelled. This ensures tagging, PyPI publishing, and GitHub release creation complete successfully.
Additionally, cancel-runs.yaml actively cancels in-progress and queued runs when a PR is closed. This complements passive concurrency groups, which only trigger cancellation when a new run enters the same group — closing a PR doesn't produce such an event.
Tip
For implementation details on how concurrency groups are computed and why release.yaml needs special handling, see claude.md § Concurrency implementation.