julien
82911f9319
## Summary
Wire up Renovate to keep dependencies fresh without manual triage.
- **Workflow** — `.gitea/workflows/renovate.yml`: cron daily at 03:00 UTC + `workflow_dispatch`, runs on the existing self-hosted runners. Picked 03:00 specifically so Monday's tick sits inside Renovate's default `lockFileMaintenance.schedule` ("before 4am Monday") and triggers the weekly lockfile refresh in passing.
- **Config** — `renovate.json`: `config:recommended` baseline + groupings (Angular, Nx, NestJS, Prisma, Vitest, TypeScript tooling, ESLint, SWC, Tailwind), Conventional-Commits commit messages, OSV.dev as vulnerability source, dependency dashboard issue.
- **Docs** — new §5 in `docs/development.md` covering the bot onboarding (manual, one-shot), how to trigger Renovate manually, how to review its PRs. The placeholder roadmap entry is dropped from §8.
No ADR — Renovate is operational tooling, not an architectural decision (and on Gitea it's the only viable bot anyway, no real alternative to capture).
## Manual setup required after merge
The workflow is wired but inert until the bot is onboarded once on Gitea:
1. Create a non-admin Gitea user `apf-portal-bot`.
2. Add the bot as a **Write** collaborator on this repo.
3. Sign in as the bot, generate a PAT (scopes: read/write `repository`, read/write `issue`, read `user`).
4. Add the PAT as the repo secret `RENOVATE_TOKEN` (Settings → Actions → Secrets).
Detailed steps in [`docs/development.md`](docs/development.md) → "Dependency updates (Renovate)".
## Test plan
- [ ] After bot onboarding, trigger the workflow manually (Repo → Actions → Renovate → Run workflow).
- [ ] First run creates the "Renovate Dependency Dashboard" issue and a batch of grouped PRs (Angular, Nx, …).
- [ ] Each generated PR has CI green (`check`, `scan`, `commits`, `perf`, `a11y`).
- [ ] Commit subject matches `chore(deps): …` / `fix(deps): …` so the `commits` gate doesn't reject.
---------
Co-authored-by: Julien Gautier <julien.gautier@apf.asso.fr>
Reviewed-on: #11
46 lines
1.8 KiB
YAML
46 lines
1.8 KiB
YAML
# Per ADR-0015 (CI/CD on Gitea Actions). Scheduled invocation of
|
|
# Renovate Bot, which proposes dependency updates as PRs against main.
|
|
#
|
|
# Configuration of the *bot's behaviour* (groupings, schedules, labels,
|
|
# auto-merge, vulnerability sources) lives in /renovate.json at the
|
|
# repo root. This workflow only controls *when* Renovate runs and how
|
|
# it authenticates against Gitea.
|
|
#
|
|
# Authentication: a Gitea Personal Access Token issued for the dedicated
|
|
# `apf-portal-bot` user, stored as the RENOVATE_TOKEN secret. The full
|
|
# bot-onboarding procedure lives in docs/development.md → "Dependency
|
|
# updates (Renovate)".
|
|
|
|
name: Renovate
|
|
|
|
on:
|
|
schedule:
|
|
# Daily 03:00 UTC — outside working hours, no contention with PR CI.
|
|
# Picked specifically to sit inside Renovate's default
|
|
# `lockFileMaintenance.schedule` window of "before 4am on Monday",
|
|
# so Monday's run also triggers the weekly lockfile refresh.
|
|
- cron: '0 3 * * *'
|
|
workflow_dispatch:
|
|
|
|
jobs:
|
|
renovate:
|
|
runs-on: [self-hosted, on-prem]
|
|
steps:
|
|
- uses: renovatebot/github-action@v40
|
|
with:
|
|
token: ${{ secrets.RENOVATE_TOKEN }}
|
|
configurationFile: renovate.json
|
|
env:
|
|
# Tell Renovate this is Gitea, not GitHub.
|
|
RENOVATE_PLATFORM: gitea
|
|
# Gitea API endpoint — derived from the workflow's own server
|
|
# URL so a Gitea → GitLab migration only requires changing
|
|
# github.server_url at the platform level (matches the
|
|
# CLAUDE.md rule about not hardcoding the project name /
|
|
# forge details outside repo metadata).
|
|
RENOVATE_ENDPOINT: ${{ github.server_url }}/api/v1/
|
|
# Don't crawl the whole instance — only this repo.
|
|
RENOVATE_AUTODISCOVER: 'false'
|
|
RENOVATE_REPOSITORIES: ${{ github.repository }}
|
|
LOG_LEVEL: info
|