Advanced

Version pinning

Two independent versions are involved when running the action:

1. The action itself — pinned via the uses: ref.
2. The CLI binary the action downloads — pinned via the version input.

For most teams, pullminder/action@v1 (action) plus version: latest (CLI) is fine. For audit-sensitive repositories or rule registries that publish to the official Pullminder registry, pin both:

- uses: pullminder/action@v1.0.0
  with:
    version: "0.1.15"

The action repository ships a floating v1 tag that is moved forward to the latest v1.x.y. Pinning to the major (@v1) keeps you on the latest non-breaking release.

Monorepo layouts

If your registry is a subdirectory of a larger monorepo, set working-directory and scope the workflow paths so the job only runs on relevant changes:

on:
  pull_request:
    paths:
      - "registry/**"

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: pullminder/action@v1
        with:
          working-directory: ./registry

Self-hosted runners

The action runs on any GitHub-hosted or self-hosted runner that satisfies all of:

• POSIX shell (bash).
• curl available on the PATH.
• Either sha256sum (Linux) or shasum (macOS) available on the PATH.
• sudo available without a password for moving the binary to /usr/local/bin. On most ephemeral runners this is the default; on a long-lived runner, allowlist the action user via /etc/sudoers.d/.

If your self-hosted runners do not provide passwordless sudo, open an issue — we are tracking a bin-path input that would let the action install the binary into a per-runner $HOME/.local/bin instead.

Matrix runs

Validate against multiple CLI versions in a single PR check (useful while bumping a registry to a newer schema):

jobs:
  validate:
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        cli: ["0.1.14", "0.1.15"]
    steps:
      - uses: actions/checkout@v4
      - uses: pullminder/action@v1
        with:
          version: ${{ matrix.cli }}
          comment: "false"

comment: "false" avoids posting one PR comment per matrix leg.

Platform support

The action downloads CLI binaries published by pullminder/cli for these targets:

Runner	Supported
ubuntu-latest	yes
ubuntu-22.04	yes
macos-latest	yes
macos-13 / -14	yes
windows-*	not yet

Windows runners are not supported today because the action’s installation step assumes /usr/local/bin and sudo. Track the action issue tracker for progress.

Security: SHA256 verification

Before the action makes the downloaded CLI binary executable, it:

1. Downloads pullminder-<os>-<arch> from the requested pullminder/cli release.
2. Downloads the matching checksums.txt from the same release.
3. Computes the SHA256 of the downloaded binary using sha256sum (or shasum -a 256 on macOS).
4. Looks up the expected hash in checksums.txt.
5. Refuses to run if the hash is missing or does not match.

This guards against tampering with the GitHub release artifacts (or with any caching layer in front of them). If your organisation requires a stricter chain of custody, mirror the binaries to your own CDN, publish a checksums.txt next to them, and either fork the action or fall back to running the CLI directly from a curl-pipe in your workflow.

Caching

The action caches the verified binary at /usr/local/bin/pullminder keyed by version + os + arch. The cache is restored from GitHub Actions cache, so cold runs incur one download per platform per version, and warm runs skip the download entirely. The cache does not skip the SHA256 check — that runs only when the cache misses.