`gitleaks/gitleaks-action@v2` is now paywalled for organisations:
the action errors out with `🛑 missing gitleaks license. Go grab one
at gitleaks.io and store it as a GitHub Secret named
GITLEAKS_LICENSE.` Worse, it cannot reliably detect personal-vs-org
on Gitea (the GitHub API contract differs), so it defaults to
license enforcement and the scan fails. The gitleaks binary itself
remains MIT-licensed and free.
Mirror the pattern we just adopted for Trivy in #45: drop the
wrapper, install the binary directly via curl + tar from the GitHub
release, run the CLI. This:
- removes a third-party action dependency we did not need;
- pins the gitleaks version explicitly;
- harmonises with the Trivy step that lives next to it.
Apply the same change to `.gitea/workflows/security-scheduled.yml`
in the same PR — it had both broken integrations (`trivy-action
@master` plus `gitleaks-action@v2`) and was waiting silently to
fail at next Monday's cron.
Per-PR gitleaks scan uses `--no-git --source .` (working tree only)
since the scan job uses a shallow checkout; the weekly scheduled
job switches to a full clone (`fetch-depth: 0`) and runs gitleaks
in deep-history mode (default), which is the value-add of the
scheduled job over the per-PR gate.
`--redact` is added on both invocations so any matched secret is
masked in the CI log itself (no leak via the log artefact).
Also drop `cache: 'pnpm'` from `actions/setup-node` in the
scheduled workflow — we already removed it from ci.yml in #8 (the
act_runner cache server is unreachable from job containers; every
restore burns ~2 min ETIMEDOUT for zero hits). Consistency.
Julien Gautier