chore(ci): track trivy and gitleaks binary versions via renovate custom manager #78

2026-05-10T04:06:55+02:00

julien commented

2026-05-10 04:06:55 +02:00

Summary

Until now the Trivy and gitleaks pins in .gitea/workflows/*.yml were manual — Renovate's built-in managers only see package-manager-tracked deps (npm, docker-compose images, GitHub Actions, etc.) and ignore plain env vars. The comment in each workflow telling the next contributor to "bump manually from the releases page" is the kind of friction that gets forgotten between two security advisories.

Add a custom regex manager that picks up # renovate: datasource=… depName=… annotations immediately followed by an env-var assignment of the form <NAME>_VERSION: '<version>'. The 4 pins (TRIVY_VERSION + GITLEAKS_VERSION in both ci.yml and security-scheduled.yml) get annotated with the github-releases datasource and the upstream owner/repo depName.

extractVersionTemplate: ^v?(?<version>.+)$ strips the v prefix used by both projects' release tags, so the version substituted into the env var (which our shell script consumes without v) stays correct.

What lands

renovate.json — new customManagers block. The dashboard triage header is updated to reflect the new tracking (was "not Renovate-tracked yet").
.gitea/workflows/ci.yml — annotate the Trivy and gitleaks env vars; remove the dead "manual bump" comments.
.gitea/workflows/security-scheduled.yml — same.

Verified

Node-side dry-run of the regex against both workflow files:

ci.yml                       → trivy 0.70.0, gitleaks 8.21.0
security-scheduled.yml       → trivy 0.70.0, gitleaks 8.21.0

All 4 expected matches with the right datasource / depName / currentValue captures.

Test plan

CI green on this PR.
After merge, the next Renovate run picks up Trivy and gitleaks as detected dependencies in the dashboard. New patch / minor releases should now produce normal Renovate PRs (auto-merging on patches per #74).
No manual "bump from the releases page" reminders left in the workflow YAML.

## Summary Until now the Trivy and gitleaks pins in `.gitea/workflows/*.yml` were manual — Renovate's built-in managers only see package-manager-tracked deps (npm, docker-compose images, GitHub Actions, etc.) and ignore plain env vars. The comment in each workflow telling the next contributor to "bump manually from the releases page" is the kind of friction that gets forgotten between two security advisories. Add a **custom regex manager** that picks up `# renovate: datasource=… depName=…` annotations immediately followed by an env-var assignment of the form `<NAME>_VERSION: '<version>'`. The 4 pins (`TRIVY_VERSION` + `GITLEAKS_VERSION` in both `ci.yml` and `security-scheduled.yml`) get annotated with the `github-releases` datasource and the upstream `owner/repo` depName. `extractVersionTemplate: ^v?(?<version>.+)$` strips the `v` prefix used by both projects' release tags, so the version substituted into the env var (which our shell script consumes without `v`) stays correct. ## What lands - **`renovate.json`** — new `customManagers` block. The dashboard triage header is updated to reflect the new tracking (was "not Renovate-tracked yet"). - **`.gitea/workflows/ci.yml`** — annotate the Trivy and gitleaks env vars; remove the dead "manual bump" comments. - **`.gitea/workflows/security-scheduled.yml`** — same. ## Verified Node-side dry-run of the regex against both workflow files: ``` ci.yml → trivy 0.70.0, gitleaks 8.21.0 security-scheduled.yml → trivy 0.70.0, gitleaks 8.21.0 ``` All 4 expected matches with the right `datasource` / `depName` / `currentValue` captures. ## Test plan - [ ] CI green on this PR. - [ ] After merge, the next Renovate run picks up Trivy and gitleaks as detected dependencies in the dashboard. New patch / minor releases should now produce normal Renovate PRs (auto-merging on patches per #74). - [ ] No manual "bump from the releases page" reminders left in the workflow YAML.

julien added 1 commit 2026-05-10 04:06:55 +02:00

chore(ci): track trivy and gitleaks binary versions via renovate custom manager

CI / commits (pull_request) Successful in 1m15s

Details

CI / check (pull_request) Successful in 1m23s

Details

CI / scan (pull_request) Successful in 1m26s

Details

CI / a11y (pull_request) Successful in 1m22s

Details

CI / perf (pull_request) Successful in 2m42s

Details

f396140786

Until now the Trivy and gitleaks pins in .gitea/workflows/*.yml
were manual — Renovate's built-in managers only see
package-manager-tracked deps (npm, docker-compose images, GitHub
Actions, etc.) and ignore plain env vars. We had a comment in
each workflow telling the next contributor to "bump manually
from the releases page", which is exactly the kind of friction
that gets forgotten between two security advisories.

Add a `customManagers` regex in renovate.json that picks up any
`# renovate: datasource=… depName=…` annotation immediately
followed by an env-var assignment of the form
`<NAME>_VERSION: '<version>'`. Annotate the four pins
(TRIVY_VERSION + GITLEAKS_VERSION in ci.yml and
security-scheduled.yml) accordingly, with the github-releases
datasource and the upstream `owner/repo` depName.

The `extractVersionTemplate: ^v?(?<version>.+)$` strips the `v`
prefix used by both projects' release tags so the version
substituted into the env var (which our shell script consumes
without `v`) stays correct.

The dashboard triage header in renovate.json that previously
listed Trivy / gitleaks under "pinned constraints — not Renovate-
tracked yet" is updated to reflect the new tracking.

Verified with a Node-side dry-run of the regex against both
workflow files: 4/4 expected matches with the right datasource /
depName / currentValue captures.

julien merged commit 4473b1d4a4 into main

2026-05-10 04:07:07 +02:00

julien deleted branch chore/ci/renovate-custom-manager-binaries

2026-05-10 04:07:10 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: julien/apf_portal#78