julien/apf_portal
1
0
Fork 0
Code Issues 1 Pull Requests Actions 1 Packages Projects Releases Wiki Activity

fix(ci): replace gitleaks-action with manual install #50

Merged
julien merged 1 commits from fix/ci/gitleaks-manual-install into main 2026-05-08 00:05:17 +02:00
Conversation 0 Commits 1 Files Changed 2
+77 -12
julien commented 2026-05-07 23:29:50 +02:00
Owner
Copy Link
Copy Source

Summary

gitleaks/gitleaks-action@v2 is now paywalled for organisations — the action requires a GITLEAKS_LICENSE secret from gitleaks.io (commercial) or it errors out:

​ 🛑 missing gitleaks license. Go grab one at gitleaks.io and store it as a GitHub Secret named GITLEAKS_LICENSE. ​

Worse, on Gitea it cannot reliably detect personal-vs-org accounts (different API contract), so it defaults to license enforcement and the scan always fails. The gitleaks binary itself stays MIT-licensed and free — only the wrapper went commercial.

Mirror the pattern from #45 (Trivy): drop the wrapper, install the binary directly via curl + tar, run the CLI.

Scope of the PR

The same two broken integrations existed in .gitea/workflows/security-scheduled.yml and would have failed silently at next Monday's cron. Fix both files in one PR for consistency.

  • ci.yml — gitleaks step replaced. Per-PR scan uses --no-git --source . (working tree only — the scan job uses a shallow checkout anyway).
  • security-scheduled.yml — both gitleaks AND trivy steps replaced; fetch-depth: 0 added so gitleaks can do its deep history scan here (the value-add of the scheduled job over the per-PR gate); cache: 'pnpm' dropped from actions/setup-node (consistency with #8 — the act_runner cache server is unreachable from job containers).
  • --redact on both gitleaks invocations so any matched secret is masked in the CI log itself (avoids re-leaking via log artefacts).

Trade-off

Like Trivy, gitleaks version is now manually pinned. Same comment in the workflow points to releases for bumps.

Test plan

  • scan job goes green end-to-end on this PR (audit ✓, Trivy ✓, gitleaks ✓).
  • gitleaks version line in the install step's logs shows 8.21.0.
  • On push to main post-merge, scan stays green.
  • Trigger security-scheduled manually (Actions → Run workflow) to verify the deep-history scan path before next Monday's cron fires.
## Summary `gitleaks/gitleaks-action@v2` is now paywalled for organisations — the action requires a `GITLEAKS_LICENSE` secret from gitleaks.io (commercial) or it errors out: ​``` 🛑 missing gitleaks license. Go grab one at gitleaks.io and store it as a GitHub Secret named GITLEAKS_LICENSE. ​``` Worse, on Gitea it cannot reliably detect personal-vs-org accounts (different API contract), so it defaults to license enforcement and the scan always fails. The **gitleaks binary itself stays MIT-licensed and free** — only the wrapper went commercial. Mirror the pattern from #45 (Trivy): drop the wrapper, install the binary directly via curl + tar, run the CLI. ## Scope of the PR The same two broken integrations existed in `.gitea/workflows/security-scheduled.yml` and would have failed silently at next Monday's cron. Fix both files in one PR for consistency. - **`ci.yml`** — gitleaks step replaced. Per-PR scan uses `--no-git --source .` (working tree only — the scan job uses a shallow checkout anyway). - **`security-scheduled.yml`** — both gitleaks AND trivy steps replaced; `fetch-depth: 0` added so gitleaks can do its **deep history scan** here (the value-add of the scheduled job over the per-PR gate); `cache: 'pnpm'` dropped from `actions/setup-node` (consistency with #8 — the act_runner cache server is unreachable from job containers). - `--redact` on both gitleaks invocations so any matched secret is masked in the CI log itself (avoids re-leaking via log artefacts). ## Trade-off Like Trivy, gitleaks version is now manually pinned. Same comment in the workflow points to releases for bumps. ## Test plan - [ ] `scan` job goes green end-to-end on this PR (audit ✓, Trivy ✓, gitleaks ✓). - [ ] `gitleaks version` line in the install step's logs shows `8.21.0`. - [ ] On `push` to main post-merge, scan stays green. - [ ] Trigger `security-scheduled` manually (Actions → Run workflow) to verify the deep-history scan path before next Monday's cron fires.
julien added 1 commit 2026-05-07 23:29:51 +02:00
fix(ci): replace gitleaks-action with manual install
CI / commits (pull_request) Successful in 2m9s
Details
CI / check (pull_request) Successful in 2m31s
Details
CI / scan (pull_request) Failing after 3m17s
Details
CI / a11y (pull_request) Successful in 1m41s
Details
CI / perf (pull_request) Successful in 3m1s
Details
7adc6e33f5 
`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 merged commit 0d27f835c3 into main 2026-05-08 00:05:17 +02:00
julien deleted branch fix/ci/gitleaks-manual-install 2026-05-08 00:05:18 +02:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adastra-bot (AdAstra Bot) julien (Julien Gautier)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: julien/apf_portal#50
Delete Branch "fix/ci/gitleaks-manual-install"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?