Files
apf_portal/.gitea/workflows/renovate.yml
T
julien f58cf13e33
CI / check (push) Successful in 2m24s
CI / commits (push) Has been skipped
CI / scan (push) Failing after 1m8s
CI / a11y (push) Successful in 1m32s
CI / perf (push) Successful in 2m52s
fix(ci): give Renovate a git identity and a github.com token (#13)
## Summary
First successful Renovate run (after the docker-image fix in #12) extracted 116 deps cleanly but every branch update failed with `fatal: empty ident name not allowed`, then the whole repo aborted on `Lock file error - aborting`. Two root causes:

- **No git identity** — the bot user had an email but no **Full Name** on its Gitea profile, so Renovate produced incomplete git authorship.
- **No github.com auth** — Renovate could not look up versions of GitHub-hosted Actions (`actions/checkout`, etc.) or `containerbase/node-prebuild` (the Node binary it dynamically fetches for lockfile maintenance) — anonymous rate limit (60 req/h) hit.

Fixes:

1. **`renovate.json`** — pin `gitAuthor` explicitly. The Full Name was also set on the bot's Gitea profile for UI consistency, but the override in config means we don't depend on out-of-band UI state.
2. **`.gitea/workflows/renovate.yml`** — pass `RENOVATE_GITHUB_COM_TOKEN` from the new `GITHUBCOM_TOKEN` repo secret (no underscore between GITHUB and COM — Gitea reserves the `GITHUB_*` namespace).
3. **`docs/development.md`** — onboarding procedure now covers both tokens + the Full Name step.

## Manual setup required after merge
Already done in this iteration:
- Bot's Full Name set in Gitea ("APF Portal Bot").
- `GITHUBCOM_TOKEN` repo secret created with a zero-scope github.com PAT.

(If the PAT was leaked during setup, regenerate before merging — the workflow only references the secret name, not the value.)

## Test plan
- [ ] After merge, trigger Renovate manually (Actions → Renovate → Run workflow).
- [ ] No `empty ident name` warning in the logs.
- [ ] No `Lock file error - aborting`; repo finishes with `INFO: Repository finished … "cloned": true`.
- [ ] Renovate creates the dependency dashboard issue + the first batch of grouped PRs (Angular, Nx, NestJS, Prisma, …) signed by `apf-portal-bot`.

---------

Co-authored-by: Julien Gautier <julien.gautier@apf.asso.fr>
Reviewed-on: #13
2026-05-05 13:47:30 +02:00

77 lines
3.4 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.
#
# Implementation note — we run the official `renovate/renovate` Docker
# image directly via `docker run` rather than the `renovatebot/github-
# action` wrapper. The wrapper relies on act_runner being able to
# resolve arbitrary GitHub tags via go-git, which is brittle (we hit
# `reference not found` on `@v40`). Going straight to the image:
# * decouples from action-tag resolution issues;
# * pins the Renovate runtime version explicitly (reproducible);
# * one fewer layer of indirection to debug.
#
# Renovate clones the repo itself using RENOVATE_TOKEN — no
# `actions/checkout` step, no host bind-mount needed.
#
# 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:
- name: Run Renovate
# Pin to the major; the bot will propose its own bumps once
# it is healthy (Renovate self-updates the workflow files it
# finds in the repo it manages).
run: |
docker run --rm \
--name "renovate-${{ github.run_id }}" \
-e RENOVATE_TOKEN \
-e RENOVATE_PLATFORM \
-e RENOVATE_ENDPOINT \
-e RENOVATE_AUTODISCOVER \
-e RENOVATE_REPOSITORIES \
-e RENOVATE_GITHUB_COM_TOKEN \
-e LOG_LEVEL \
renovate/renovate:40
env:
RENOVATE_TOKEN: ${{ secrets.RENOVATE_TOKEN }}
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 }}
# Read-only authenticated GitHub.com token (zero-scope PAT) so
# Renovate can resolve versions of GitHub-hosted Actions and
# the `containerbase/node-prebuild` binaries it uses for
# lockfile maintenance, without hitting the 60 req/h
# anonymous rate limit. Stored under GITHUBCOM_TOKEN (no
# underscore) because Gitea reserves the GITHUB_* secret
# namespace for its built-in `${{ github.* }}` context.
RENOVATE_GITHUB_COM_TOKEN: ${{ secrets.GITHUBCOM_TOKEN }}
LOG_LEVEL: info