Quand ce repo tague une release, l'image jcabillot/ip part sur Docker Hub, mais le bump d'image dans perso_private/tf-depl-kubernetes attend le prochain passage horaire de Renovate (CronJob K8s, schedule 12 * * * *) : jusqu'à ~60 min de latence entre le tag et la PR de bump.
Changement
Un job trigger-renovate en fin de .gitea/workflows/tag.yaml : dès que le job build-push (image jcabillot/ip) est terminé, il déclenche le workflow Renovate de perso_private/tf-depl-kubernetes via l'API Gitea (workflow_dispatch, déjà activé dans ce repo).
needs: [build-push] : Renovate doit scanner après que l'image existe sur Docker Hub, sinon le scan lit la release précédente et ne propose rien.
Auth : secret d'org RENOVATE_TOKEN de l'org web — le token du bot Renovate, déjà en place, aucun nouveau credential.
Échec bruyant (pas de continue-on-error) : un token cassé doit se voir, pas se taire.
Même mécanisme que web/mydl (PR #420), validé de bout en bout sur la release v0.0.222 (dispatch → PR de bump à jour en 80 s).
Portée
Aucun impact sur l'image de release ni sur les jobs existants : le nouveau job ne fait qu'un appel HTTP après le push.
## Problème
Quand ce repo tague une release, l'image `jcabillot/ip` part sur Docker Hub, mais le bump d'image dans `perso_private/tf-depl-kubernetes` attend le prochain passage horaire de Renovate (CronJob K8s, schedule `12 * * * *`) : jusqu'à **~60 min** de latence entre le tag et la PR de bump.
## Changement
Un job `trigger-renovate` en fin de `.gitea/workflows/tag.yaml` : dès que le job `build-push` (image `jcabillot/ip`) est terminé, il déclenche le workflow Renovate de `perso_private/tf-depl-kubernetes` via l'API Gitea (`workflow_dispatch`, déjà activé dans ce repo).
- `needs: [build-push]` : Renovate doit scanner **après** que l'image existe sur Docker Hub, sinon le scan lit la release précédente et ne propose rien.
- Auth : secret d'org `RENOVATE_TOKEN` de l'org `web` — le token du bot Renovate, déjà en place, aucun nouveau credential.
- Échec **bruyant** (pas de `continue-on-error`) : un token cassé doit se voir, pas se taire.
Même mécanisme que `web/mydl` (PR #420), validé de bout en bout sur la release v0.0.222 (dispatch → PR de bump à jour en 80 s).
## Portée
Aucun impact sur l'image de release ni sur les jobs existants : le nouveau job ne fait qu'un appel HTTP après le push.
A release only reached perso_private/tf-depl-kubernetes on the next hourly
Renovate scan, so the image bump PR could lag up to an hour behind the tag.
After the image push completes, dispatch that repo's Renovate workflow through
the Gitea API (workflow_dispatch is already enabled there). It authenticates
with the RENOVATE_TOKEN org secret of this organisation — the same token the
Renovate instance itself uses, no extra credential. The job fails loudly so a
rotated token shows up instead of the trigger silently going missing.
opencodecabilloteu
requested review from jcabillot 2026-10-18 13:24:28 -04:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Problème
Quand ce repo tague une release, l'image
jcabillot/ippart sur Docker Hub, mais le bump d'image dansperso_private/tf-depl-kubernetesattend le prochain passage horaire de Renovate (CronJob K8s, schedule12 * * * *) : jusqu'à ~60 min de latence entre le tag et la PR de bump.Changement
Un job
trigger-renovateen fin de.gitea/workflows/tag.yaml: dès que le jobbuild-push(imagejcabillot/ip) est terminé, il déclenche le workflow Renovate deperso_private/tf-depl-kubernetesvia l'API Gitea (workflow_dispatch, déjà activé dans ce repo).needs: [build-push]: Renovate doit scanner après que l'image existe sur Docker Hub, sinon le scan lit la release précédente et ne propose rien.RENOVATE_TOKENde l'orgweb— le token du bot Renovate, déjà en place, aucun nouveau credential.continue-on-error) : un token cassé doit se voir, pas se taire.Même mécanisme que
web/mydl(PR #420), validé de bout en bout sur la release v0.0.222 (dispatch → PR de bump à jour en 80 s).Portée
Aucun impact sur l'image de release ni sur les jobs existants : le nouveau job ne fait qu'un appel HTTP après le push.