julien
4473b1d4a4
## 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. --------- Co-authored-by: Julien Gautier <julien.gautier@apf.asso.fr> Reviewed-on: #78
Documentation index
This is the entry point to all project documentation. It is maintained automatically: any addition, rename, or removal of a .md file under docs/ must be reflected here in the same change.
Conventions
- Documentation is written in English.
- One topic per file. Group related files into a folder when there are three or more.
- Cross-reference with relative links so they keep working in GitHub, IDEs, and exported sites.
- For architectural decisions, do not add them here — they belong in decisions/ as MADR 4.0.0 ADRs.
Sections
Daily development
- development.md — repo layout, prerequisites, initial setup, daily commands, observability dev-loop (Jaeger UI, log ↔ trace correlation), dependency updates (Renovate), conventional commit cycle. Day-to-day reference for working on the project.
Architecture
- architecture.md — cross-cutting Mermaid diagrams: C4 system context, C4 containers, Nx module boundaries, CI/CD pipeline. Single-decision diagrams (auth sequence, ERD, etc.) live inline in their ADR.
Onboarding & environment
Setup guides for new contributors:
- setup/01-wsl-terminal-setup.md — modern WSL terminal (Zsh + Powerlevel10k + CLI tools)
- setup/02-dev-web-stack.md — Node via nvm, pnpm via corepack, Docker
- setup/03-angular-nx-monorepo.md — Angular + Nx monorepo bootstrap
Operations & runbooks
Empty — to be populated when we deploy.
Security, performance, accessibility
Empty — placeholders to be filled with rationale docs alongside their corresponding ADRs.