Objectif
Sortir Renovate de GitHub Actions et le faire tourner dans le cluster, en CronJob Kubernetes, sur le nœud de calcul auto-hébergé.
Pourquoi
La file d'attente. Renovate consomme un slot de runner à chaque exécution, sur un parc de 9 slots partagés par 12 dépôts privés, avec une file médiane déjà mesurée à ~45 min. Renovate attend, et pendant qu'il tourne il prive les builds d'un slot.
La fréquence est contrainte par ce coût. Le cron est à 0 */6 * * *. Hors CI, la fréquence redevient un choix libre.
Le cache. Chaque exécution GitHub Actions repart d'un cache froid. Un CronJob avec un volume persistant conserve le cache Renovate entre les runs, ce qui est le principal levier de vitesse sur un scan multi-dépôts.
La capacité. Le nœud MS-A2 (16C/32T) absorbe un scan d'organisation sans concurrencer quoi que ce soit.
Le point dur : le callback de la checkbox
Le mécanisme actuel doit être remplacé, pas supprimé.
Aujourd'hui : renovate-rebase.yml dans chaque dépôt écoute pull_request: types: [edited], appelle reusable-renovate-dispatch.yml, qui mint un jeton de la GitHub App Renovate et déclenche renovate.yml avec un repoFilter ciblé. Réaction en secondes plutôt qu'à la prochaine passe du cron.
Une fois Renovate hors de GitHub Actions, il n'y a plus de workflow_dispatch à déclencher.
Remplacement proposé
Webhook de la GitHub App Renovate au niveau organisation → récepteur HTTP dans le cluster → création d'un Job Renovate ciblé sur le dépôt concerné.
Cette brique existe déjà : la crate Kit ferrlabs-webhooks et le récepteur GitHub de FerrFleet (api.ferrfleet.com/api/v1/github/webhook) fournissent le modèle — vérification de signature comprise.
Bénéfice secondaire : les workflows renovate-rebase.yml disparaissent de chaque dépôt, ainsi que reusable-renovate-dispatch.yml. Plus de jeton d'App à minter côté appelant, plus de contrainte actions: write sur FerrLabs/.github, et plus de distinction runner public/privé à gérer.
Autres points à traiter
Risque à ne pas sous-estimer
Les dépôts épinglent les reusables de .github par SHA (# main), et c'est Renovate qui propage ces mises à jour. Un Renovate cassé fige silencieusement la propagation des changements de CI sur tout le parc. La bascule doit être vérifiée dépôt par dépôt avant de retirer les workflows existants, et il faut conserver un moyen de déclenchement manuel.
Références
Objectif
Sortir Renovate de GitHub Actions et le faire tourner dans le cluster, en
CronJobKubernetes, sur le nœud de calcul auto-hébergé.Pourquoi
La file d'attente. Renovate consomme un slot de runner à chaque exécution, sur un parc de 9 slots partagés par 12 dépôts privés, avec une file médiane déjà mesurée à ~45 min. Renovate attend, et pendant qu'il tourne il prive les builds d'un slot.
La fréquence est contrainte par ce coût. Le cron est à
0 */6 * * *. Hors CI, la fréquence redevient un choix libre.Le cache. Chaque exécution GitHub Actions repart d'un cache froid. Un
CronJobavec un volume persistant conserve le cache Renovate entre les runs, ce qui est le principal levier de vitesse sur un scan multi-dépôts.La capacité. Le nœud MS-A2 (16C/32T) absorbe un scan d'organisation sans concurrencer quoi que ce soit.
Le point dur : le callback de la checkbox
Le mécanisme actuel doit être remplacé, pas supprimé.
Aujourd'hui :
renovate-rebase.ymldans chaque dépôt écoutepull_request: types: [edited], appellereusable-renovate-dispatch.yml, qui mint un jeton de la GitHub App Renovate et déclencherenovate.ymlavec unrepoFilterciblé. Réaction en secondes plutôt qu'à la prochaine passe du cron.Une fois Renovate hors de GitHub Actions, il n'y a plus de
workflow_dispatchà déclencher.Remplacement proposé
Webhook de la GitHub App Renovate au niveau organisation → récepteur HTTP dans le cluster → création d'un
JobRenovate ciblé sur le dépôt concerné.Cette brique existe déjà : la crate Kit
ferrlabs-webhookset le récepteur GitHub de FerrFleet (api.ferrfleet.com/api/v1/github/webhook) fournissent le modèle — vérification de signature comprise.Bénéfice secondaire : les workflows
renovate-rebase.ymldisparaissent de chaque dépôt, ainsi quereusable-renovate-dispatch.yml. Plus de jeton d'App à minter côté appelant, plus de contrainteactions: writesurFerrLabs/.github, et plus de distinction runner public/privé à gérer.pull_request.edited+ garde anti-boucle équivalente à celle du dispatch actuel)concurrency: group: renovateAutres points à traiter
RENOVATE_APP_CLIENT_IDetRENOVATE_APP_PRIVATE_KEYpassent des secrets d'organisation GitHub à OpenBao, synchronisés par VSOplanproduit aujourd'hui une matrice de shards. Décider entre parallélisme duJobet exécution séquentielle avec cache chaudPackages (R), Renovate obtient des 401 et n'émet silencieusement aucune PR pour les libs internes@ferrlabs/*renovate-selfcheck.yml: décider de son sortCronJobva sur le nœud maison (charge de calcul, aucune donnée client) — cf. FerrLabs/Kubernetes#212Risque à ne pas sous-estimer
Les dépôts épinglent les reusables de
.githubpar SHA (# main), et c'est Renovate qui propage ces mises à jour. Un Renovate cassé fige silencieusement la propagation des changements de CI sur tout le parc. La bascule doit être vérifiée dépôt par dépôt avant de retirer les workflows existants, et il faut conserver un moyen de déclenchement manuel.Références
FerrLabs/.github:renovate.yml,renovate-rebase.yml,reusable-renovate-dispatch.yml,renovate-selfcheck.yml