ci: vendor gitleaks-action on Forgejo so uses: no longer resolves to GitHub #27

Merged

ullrich merged 1 commit from ci/vendor-gitleaks-action-on-forgejo into main 2026-07-27 18:14:11 +00:00

Conversation 1 Commits 1 Files changed 1 +22 -1

ullrich commented 2026-07-27 17:48:36 +00:00

Owner

Copy link

CI's security scan resolved uses: https://github.com/trails-cool/gitleaks-action@<sha>, so "GitHub is retired" was not literally true — every run fetched an action from a host we had otherwise stopped depending on. If that repo or GitHub went away, Security Scan would fail on every PR.

What changed

Migrated the fork to git.ullrich.is/trails-cool/gitleaks-action as a one-time copy, not a pull-mirror. A mirror would have kept the GitHub coupling alive behind a sync job, which defeats the point.

The pinned SHA is unchanged. A git migration preserves commit IDs, so 4cbc857b resolves to the same object, same commit message, same 5.2MB dist/index.js. This is a pure hosting change — the action's bytes are identical to what CI ran before this PR.

Verified before switching the reference

check	result
branches carried over	trails-cool @ 4cbc857b, master @ bf2dc8e5
pinned SHA exists on new remote	yes, identical commit message
dist/index.js at that SHA	5,227,118 bytes (action ships built — must run without a build step)
action.yml at that SHA	510 bytes
anonymous HTTPS + git-upload-pack	both 200 — runner can fetch without credentials

That last one mattered most: the action is fetched by the runner, so if the new repo needed auth the job would fail in a way that looks like a bad uses: reference.

The finding worth acting on separately

The fork's entire delta over upstream gitleaks/gitleaks-action is two commits:

b627dab5  Add support for "merge_group" event
4cbc857b  Merge remote-tracking branch 'take-five/feat/support-merge-group' into trails-cool

merge_group is a GitHub merge-queue event. Forgejo has no merge queue (#25), and ci.yml has never used a merge_group trigger. So the only reason this fork exists is obsolete, and it is 8 commits behind upstream.

Rebasing onto current upstream and dropping the patch would let us track upstream cleanly. That is deliberately not in this PR: changing the host and the content together would mean a CI failure could not be attributed to either. This PR changes one variable.

Note that dropping the fork entirely in favour of gitleaks/gitleaks-action would not have solved the original problem — upstream is also GitHub-hosted. Vendoring was the only route that removes the dependency.

How this PR proves itself

The CI / Security Scan check on this very PR is the test: it is the job that resolves the uses: line. If it goes green, the vendored action fetched and ran from Forgejo.

CI's security scan resolved `uses: https://github.com/trails-cool/gitleaks-action@<sha>`, so **"GitHub is retired" was not literally true** — every run fetched an action from a host we had otherwise stopped depending on. If that repo or GitHub went away, Security Scan would fail on every PR. ## What changed Migrated the fork to `git.ullrich.is/trails-cool/gitleaks-action` as a **one-time copy, not a pull-mirror**. A mirror would have kept the GitHub coupling alive behind a sync job, which defeats the point. **The pinned SHA is unchanged.** A git migration preserves commit IDs, so `4cbc857b` resolves to the same object, same commit message, same 5.2MB `dist/index.js`. This is a pure hosting change — the action's bytes are identical to what CI ran before this PR. ## Verified before switching the reference | check | result | |---|---| | branches carried over | `trails-cool` @ `4cbc857b`, `master` @ `bf2dc8e5` | | pinned SHA exists on new remote | yes, identical commit message | | `dist/index.js` at that SHA | 5,227,118 bytes (action ships built — must run without a build step) | | `action.yml` at that SHA | 510 bytes | | anonymous HTTPS + `git-upload-pack` | both 200 — runner can fetch without credentials | That last one mattered most: the action is fetched by the runner, so if the new repo needed auth the job would fail in a way that looks like a bad `uses:` reference. ## The finding worth acting on separately The fork's **entire** delta over upstream `gitleaks/gitleaks-action` is two commits: ``` b627dab5 Add support for "merge_group" event 4cbc857b Merge remote-tracking branch 'take-five/feat/support-merge-group' into trails-cool ``` `merge_group` is a **GitHub merge-queue event**. Forgejo has no merge queue (#25), and `ci.yml` has never used a `merge_group` trigger. So the only reason this fork exists is obsolete, and it is 8 commits behind upstream. Rebasing onto current upstream and dropping the patch would let us track upstream cleanly. That is deliberately **not** in this PR: changing the host and the content together would mean a CI failure could not be attributed to either. This PR changes one variable. Note that dropping the fork entirely in favour of `gitleaks/gitleaks-action` would *not* have solved the original problem — upstream is also GitHub-hosted. Vendoring was the only route that removes the dependency. ## How this PR proves itself The `CI / Security Scan` check on this very PR is the test: it is the job that resolves the `uses:` line. If it goes green, the vendored action fetched and ran from Forgejo.

ullrich added 1 commit 2026-07-27 17:48:36 +00:00

ci: vendor gitleaks-action on Forgejo, removing CI's last GitHub dependency ... 6beacbd022

The security scan resolved `uses: https://github.com/trails-cool/gitleaks-action@<sha>`,
so "GitHub is retired" was not literally true: every CI run fetched an action
from a host we had otherwise stopped depending on. If that repo or GitHub itself
went away, Security Scan would fail on every PR.

Migrated the fork to git.ullrich.is/trails-cool/gitleaks-action as a **one-time
copy, not a pull-mirror** — a mirror would have kept the GitHub coupling, just
hidden behind a sync job.

The pinned SHA is unchanged: a git migration preserves commit IDs, so
4cbc857b resolves to the same object with the same commit message and the same
5.2MB dist/index.js. This is a pure hosting change; the action's bytes are
identical to what CI ran before.

Verified before switching the reference:
- both branches carried over (`trails-cool` @ 4cbc857b, `master` @ bf2dc8e5)
- 4cbc857b exists on the new remote, same commit message
- `dist/index.js` and `action.yml` present at that SHA (the action ships built,
  so it must run without a build step)
- anonymous HTTPS + `git-upload-pack` both return 200, so the runner can fetch
  it without credentials

Worth recording while it is fresh: the fork's entire delta over upstream
gitleaks/gitleaks-action is two commits adding `merge_group` event support — a
GitHub merge-queue feature Forgejo does not have (issue #25). The patch is dead
weight and the fork is 8 commits behind upstream. Rebasing onto upstream and
dropping the patch is a genuine follow-up, deliberately not bundled here: mixing
a host change with a content change would mean a CI failure could not be
attributed to either one.

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

ullrich force-pushed ci/vendor-gitleaks-action-on-forgejo from 6beacbd022 to c461940fd7 2026-07-27 18:01:59 +00:00 Compare

ullrich changed title from ci: vendor gitleaks-action on Forgejo, removing CI's last GitHub dependency to ci: vendor gitleaks-action on Forgejo so uses: no longer resolves to GitHub 2026-07-27 18:02:28 +00:00

ullrich commented 2026-07-27 18:02:28 +00:00

Author

Owner

Copy link

Correction: this does not remove CI's last GitHub dependency

I titled this PR "removing CI's last GitHub dependency". That was wrong, and the job log I pulled to verify the change is what disproved it.

What the change does do — confirmed from the Security Scan job log (run 107, job 553):

☁️  git clone 'https://git.***/trails-cool/gitleaks-action' # ref=4cbc857b…

git.*** is git.ullrich.is masked (ullrich.is is the BROUTER_DEPLOY_HOST secret value; github.com renders unmasked in the same log, so it cannot be that). And the scan genuinely ran rather than silently skipping — gitleaks 8.24.3, 1 commits scanned, no leaks found, ✅ No leaks detected. A green tick alone would not have shown either of those.

What remains. Every github.com request in that one job:

1  https://github.com/zricethezav/gitleaks/releases/download/v8.24.3/gitleaks_8.24.3_linux_x64.tar.gz
1  https://github.com/actions/checkout

• the action downloads the gitleaks binary from GitHub releases at runtime, on every run
• actions/checkout resolves through FORGEJO__actions__DEFAULT_ACTIONS_URL=github — in every job, not just this one

So if GitHub disappeared, CI would still break. What this PR fixes is narrower and still worth having: uses: no longer depends on a fork in an org we retired, which was the single-repo failure point.

Both remaining dependencies are now documented inline next to the step instead of left implied, and the commit message and the vendored repo's own description have been corrected — the description also claimed CI had "no GitHub dependency".

Removing them properly means hosting the gitleaks binary somewhere we control and mirroring the shared actions/*. That is real work with its own tradeoffs (pinning, update flow), not something to smuggle into this PR. Happy to open an issue for it.

Force-pushed 6beacbd → c461940; the only content change is the corrected comment block, so CI is re-running.

## Correction: this does not remove CI's last GitHub dependency I titled this PR "removing CI's last GitHub dependency". That was wrong, and the job log I pulled to verify the change is what disproved it. **What the change does do** — confirmed from the `Security Scan` job log (run 107, job 553): ``` ☁️ git clone 'https://git.***/trails-cool/gitleaks-action' # ref=4cbc857b… ``` `git.***` is `git.ullrich.is` masked (`ullrich.is` is the `BROUTER_DEPLOY_HOST` secret value; `github.com` renders unmasked in the same log, so it cannot be that). And the scan genuinely ran rather than silently skipping — gitleaks 8.24.3, `1 commits scanned`, `no leaks found`, `✅ No leaks detected`. A green tick alone would not have shown either of those. **What remains.** Every `github.com` request in that one job: ``` 1 https://github.com/zricethezav/gitleaks/releases/download/v8.24.3/gitleaks_8.24.3_linux_x64.tar.gz 1 https://github.com/actions/checkout ``` - the action downloads the **gitleaks binary from GitHub releases at runtime**, on every run - **`actions/checkout`** resolves through `FORGEJO__actions__DEFAULT_ACTIONS_URL=github` — in *every* job, not just this one So if GitHub disappeared, CI would still break. What this PR fixes is narrower and still worth having: `uses:` no longer depends on a fork in an org we retired, which was the single-repo failure point. Both remaining dependencies are now documented inline next to the step instead of left implied, and the commit message and the vendored repo's own description have been corrected — the description also claimed CI had "no GitHub dependency". Removing them properly means hosting the gitleaks binary somewhere we control and mirroring the shared `actions/*`. That is real work with its own tradeoffs (pinning, update flow), not something to smuggle into this PR. Happy to open an issue for it. Force-pushed `6beacbd` → `c461940`; the only content change is the corrected comment block, so CI is re-running.

ullrich merged commit 2487509616 into main 2026-07-27 18:14:11 +00:00

ullrich deleted branch ci/vendor-gitleaks-action-on-forgejo 2026-07-27 18:14:11 +00:00

ullrich referenced this pull request from a commit 2026-07-27 18:14:12 +00:00

Merge pull request 'ci: vendor gitleaks-action on Forgejo so `uses:` no longer resolves to GitHub' (#27) from ci/vendor-gitleaks-action-on-forgejo into main

ullrich referenced this pull request 2026-07-27 18:51:37 +00:00

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

ullrich referenced this pull request 2026-07-27 20:13:57 +00:00

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

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

dependencies

Dependency updates raised by Renovate (renovate.json5 labels)

  

major

Major version bump — always needs human review, never auto-merged

  

security-pin

Touches a pnpm.overrides CVE remediation pin, not an ordinary dependency

No labels

dependencies

major

security-pin

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

trails-cool/trails!27

No description provided.