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

Merged
julien merged 1 commits from chore/ci/renovate-custom-manager-binaries into main 2026-05-10 04:07:07 +02:00

1 Commits

Author SHA1 Message Date
Julien Gautier f396140786 chore(ci): track trivy and gitleaks binary versions via renovate custom manager
CI / commits (pull_request) Successful in 1m15s
CI / check (pull_request) Successful in 1m23s
CI / scan (pull_request) Successful in 1m26s
CI / a11y (pull_request) Successful in 1m22s
CI / perf (pull_request) Successful in 2m42s
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.
2026-05-10 04:05:49 +02:00