Julien Gautier
d3fc13e467
`renovatebot/github-action@v40` failed to resolve on Gitea Actions with `reference not found` when act_runner attempted the go-git clone. Whether the issue is a missing major-rolling tag upstream or a go-git tag-fetch quirk, the wrapper action is the wrong layer to fight: it just shells out to the same `renovate/renovate` image we can run ourselves. Switch to a direct `docker run renovate/renovate:40` invocation: - decouples from third-party action-tag resolution; - pins the Renovate runtime version explicitly (reproducible); - one fewer indirection to debug. The job container already has access to the host Docker daemon (per ci-runners.compose.yml mounting /var/run/docker.sock), so the sibling `docker run` works out of the box. Renovate clones the target repo itself using the API token, so no `actions/checkout` or host bind-mount is needed.
68 lines
2.8 KiB
YAML
68 lines
2.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.
|
|
#
|
|
# 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 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 }}
|
|
LOG_LEVEL: info
|