ci(gitleaks): drop the local patch, track upstream v3.0.0 unmodified #28

Merged

ullrich merged 1 commit from ci/gitleaks-track-upstream-v3 into main

2026-07-27 20:07:31 +00:00

ullrich commented

2026-07-27 18:51:37 +00:00

Owner

Answers the question directly: we still need the vendored repo, but we no longer need it to be a fork.

uses: has to resolve somewhere that isn't GitHub — pointing it back at gitleaks/gitleaks-action would undo #27. What changes is the repo's character: fork-carrying-a-patch → plain mirror of an upstream tag.

The patch was dead weight

The old pin 4cbc857b carried exactly two local commits adding merge_group event support. That is a GitHub merge-queue feature, Forgejo has no merge queue (#25), and ci.yml has never had a merge_group trigger. With it gone there is nothing local to maintain, and updating becomes "push a newer upstream tag, bump the SHA".

Now pinned to upstream v3.0.0 (e0c47f4f), unmodified.

Verified on the vendored remote before switching

check	result
`e0c47f4f` present	yes — "chore: migrate to Node 24 runtime (v3)"
`dist/index.js` at that SHA	5,174,071 bytes (action ships built)
`action.yml` at that SHA	`using: "node24"`, `main: dist/index.js`
`merge_group` occurrences	0 — patch genuinely dropped
`GITLEAKS_ENABLE_UPLOAD_ARTIFACT`	2 occurrences — honoured

That last one was worth checking rather than assuming: if the env var had been something our fork added, dropping the patch would have silently re-enabled the SARIF artifact upload, which throws GHESNotSupportedError against Forgejo and would fail the job on a clean scan. It turns out to be an upstream feature, so the workaround survives.

The one real risk

v3.0.0 migrates the action runtime node20 → node24:

old pin (4cbc857b):  using: "node20"
new pin (e0c47f4f):  using: "node24"

If the runner cannot provide node24, the step fails to start. I have not asserted that it can — CI is the test, and CI / Security Scan on this PR is the job that resolves and executes the action. The fallback is documented inline: upstream bf2dc8e5, the pre-v3 commit our fork branched from, which is node20 and also patch-free. That would drop the patch without taking the runtime jump, at the cost of staying ~a year behind upstream (and missing chore: supply-chain hardening).

If Security Scan fails here, the fix is a one-line SHA change to that fallback, not a revert.

Unchanged, still documented next to the step

The action still downloads the gitleaks binary from github.com/zricethezav/gitleaks/releases every run, and actions/* still resolve via DEFAULT_ACTIONS_URL=github. This PR is about the fork, not those — CI is not GitHub-free and the inline comment still says so.

Answers the question directly: **we still need the vendored repo, but we no longer need it to be a fork.** `uses:` has to resolve *somewhere* that isn't GitHub — pointing it back at `gitleaks/gitleaks-action` would undo #27. What changes is the repo's character: fork-carrying-a-patch → plain mirror of an upstream tag. ## The patch was dead weight The old pin `4cbc857b` carried exactly two local commits adding **`merge_group` event support**. That is a GitHub merge-queue feature, Forgejo has no merge queue (#25), and `ci.yml` has never had a `merge_group` trigger. With it gone there is nothing local to maintain, and updating becomes "push a newer upstream tag, bump the SHA". Now pinned to **upstream v3.0.0 (`e0c47f4f`)**, unmodified. ## Verified on the vendored remote before switching | check | result | |---|---| | `e0c47f4f` present | yes — *"chore: migrate to Node 24 runtime (v3)"* | | `dist/index.js` at that SHA | 5,174,071 bytes (action ships built) | | `action.yml` at that SHA | `using: "node24"`, `main: dist/index.js` | | `merge_group` occurrences | **0** — patch genuinely dropped | | `GITLEAKS_ENABLE_UPLOAD_ARTIFACT` | 2 occurrences — honoured | That last one was worth checking rather than assuming: if the env var had been something *our fork* added, dropping the patch would have silently re-enabled the SARIF artifact upload, which throws `GHESNotSupportedError` against Forgejo and would fail the job on a clean scan. It turns out to be an upstream feature, so the workaround survives. ## The one real risk v3.0.0 migrates the action runtime **node20 → node24**: ``` old pin (4cbc857b): using: "node20" new pin (e0c47f4f): using: "node24" ``` If the runner cannot provide node24, the step fails to start. I have not asserted that it can — **CI is the test**, and `CI / Security Scan` on this PR is the job that resolves and executes the action. The fallback is documented inline: upstream `bf2dc8e5`, the pre-v3 commit our fork branched from, which is node20 and also patch-free. That would drop the patch without taking the runtime jump, at the cost of staying ~a year behind upstream (and missing `chore: supply-chain hardening`). If Security Scan fails here, the fix is a one-line SHA change to that fallback, not a revert. ## Unchanged, still documented next to the step The action still downloads the gitleaks binary from `github.com/zricethezav/gitleaks/releases` every run, and `actions/*` still resolve via `DEFAULT_ACTIONS_URL=github`. This PR is about the fork, not those — CI is not GitHub-free and the inline comment still says so.

ullrich added 1 commit

2026-07-27 18:51:38 +00:00

ci(gitleaks): drop the local patch, track upstream v3.0.0 unmodified

CI / Dockerfile Package Check (pull_request) Successful in 17s

Details

CI / Security Scan (pull_request) Successful in 39s

Details

CI / Checks (pull_request) Successful in 2m49s

Details

CI / Visual Tests (pull_request) Successful in 2m52s

Details

CI / Journal Image Smoke Test (pull_request) Successful in 3m46s

Details

CI / E2E Tests (pull_request) Successful in 6m13s

Details

2699bada2e

Answers the "do we still need the fork?" question: we still need the
vendored *repo* — `uses:` has to resolve somewhere that isn't GitHub — but
we no longer need it to be a *fork*.

The old pin (4cbc857b) carried exactly two local commits adding
`merge_group` event support. That is a GitHub merge-queue feature, Forgejo
has no merge queue (issue #25), and this workflow has never had a
`merge_group` trigger. Dead weight. With it gone there is nothing local to
maintain, so the vendored repo becomes a plain mirror instead of a
divergent fork, and future updates are "push a newer upstream tag, bump the
SHA".

Now pinned to upstream v3.0.0 (e0c47f4f), verified present on the vendored
remote along with its dist/index.js (5,174,071 bytes) and action.yml.
Confirmed `merge_group` appears 0 times at that SHA, i.e. the patch really
is dropped, and `GITLEAKS_ENABLE_UPLOAD_ARTIFACT` is honoured twice — that
env var turns out to be an upstream feature, not something our fork added,
so the artifact-upload workaround survives (its @actions/artifact v2 upload
still throws GHESNotSupportedError against Forgejo).

The real risk is the runtime: v3.0.0 migrates the action from node20 to
node24. If the runner cannot provide node24 the step fails to start. That
is left for CI to answer rather than assumed, and the fallback is documented
inline — upstream bf2dc8e5, the pre-v3 commit our fork branched from, which
is node20 and also patch-free.

Deliberately still not fixed here, and still documented next to the step:
the action downloads the gitleaks binary from GitHub releases every run, and
`actions/*` resolve via DEFAULT_ACTIONS_URL=github. This change is about the
fork, not those.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01X8hNxgYp777FRqYtVmQNaU

ullrich merged commit a69638ae65 into main

2026-07-27 20:07:31 +00:00

ullrich deleted branch ci/gitleaks-track-upstream-v3

2026-07-27 20:07:31 +00:00

ullrich referenced this pull request from a commit

2026-07-27 20:07:32 +00:00

Merge pull request 'ci(gitleaks): drop the local patch, track upstream v3.0.0 unmodified' (#28) from ci/gitleaks-track-upstream-v3 into main

ullrich referenced this pull request from a commit

2026-07-27 20:13:18 +00:00

ci(gitleaks): use upstream directly; drop the vendored mirror