arcodange-org/factory
1
0
Fork 0
Code Issues 4 Pull Requests Actions Packages Projects Releases Wiki Activity

fix(cicd) — épingler la version du runner : latest + pull: missing ne rafraîchit JAMAIS #51

Merged
arcodange merged 2 commits from arcodange/runner-version-epinglee into main 2026-07-30 09:10:59 +02:00
Conversation 0 Commits 2 Files Changed 3
+56 -2
arcodange commented 2026-07-30 08:55:15 +02:00
Owner
Copy Link
Copy Source

Répond à « qu'est-ce qui nous empêche d'upgrade des deux côtés ? » — et la réponse est : rien. Personne n'avait décidé de rester en retard ; c'est une configuration qui l'imposait en silence.

Ferme la moitié « versions divergentes » de #50.

Le défaut

Le playbook déploie gitea/act_runner:**latest** avec pull: missing : la pire combinaison possible — un tag flottant qui n'est jamais rafraîchi. pull: missing ne tire l'image que si elle est absente ; les deux hôtes en ayant déjà une sous ce tag, chacun garde ce que « latest » voulait dire le jour de son premier pull.

pi1 : sha256:7bdc8d31…  →  act_runner v0.3.1
pi3 : sha256:0f65fa10…  →  act_runner v0.2.13

Deux machines censées être interchangeables, trois versions mineures d'écart. Effets mesurés :

  • le même job, sur la même image de CI : 511 s sur pi1, 397 s sur pi3 — 114 s imputables à la machine ;
  • pi3 (v0.2.13) a mal lu la définition d'un job dont il dépendait : 'runs-on' key not defined, puis No steps found.

Le correctif

Une variable dans inventory/group_vars/all/gitea.yml, et le playbook la consomme :

gitea_runner_version: "0.3.1"

⚠ pull: missing redevient correct avec un tag épinglé : changer la version change le tag, donc l'image est absente, donc elle est tirée. Pas besoin de pull: always, qui interrogerait le registre à chaque passage pour rien.

Deux choix que je veux exposer plutôt que subir

1. Pourquoi pas latest + pull: always ? Parce que latest vaut aujourd'hui 0.6.1 (Docker Hub, 30/04/2026) — 3 à 4 versions mineures devant tout ce qui est éprouvé ici. Le runner exécute toute la CI de la forge : une montée subie, non datée et non choisie s'y paie cher. On épingle, et on monte délibérément.

2. Pourquoi 0.3.1 et pas 0.6.1 ? Parce que 0.3.1 est la version que pi1 exécute déjà avec succès sur cette forge. Ce changement aligne donc pi3 vers le haut, sur du prouvé, sans saut de quatre versions sur le composant le plus critique. Passer ensuite à 0.6.1 devient une modification d'une ligne, datée et reculable — c'est tout l'intérêt de la variable.

Si tu préfères viser 0.6.1 directement, c'est défendable — mais je recommande alors de le faire sur pi3 d'abord (il ne porte pas le control-plane k3s), d'observer quelques runs, puis pi1.

⚠ À savoir avant de jouer le playbook

03_cicd.yml recrée les conteneurs de runner (loop: [absent, present]) : il tue les jobs en vol, qui deviennent failure avec leurs journaux perdus. Vérifier qu'aucun run n'est queued ni in_progress juste avant — et se rappeler qu'un merge est un déclencheur, donc que « plus rien ne tourne » se vérifie après le dernier merge.

Ici, l'effet sera une recréation sur les deux hôtes (le tag change des deux côtés), donc une re-registration des deux runners.

Vérifications

  • ✅ 03_cicd.yml parse ; image et pull relus depuis le YAML chargé (gitea/act_runner:{{ gitea_runner_version }}, pull: missing).
  • ✅ La variable se charge bien depuis group_vars/all/gitea.yml.
  • ✅ Versions constatées dans les conteneurs (act_runner --version) et digests d'images relevés sur les deux hôtes — pas déduits.
  • ✅ latest = 0.6.1 vérifié sur Docker Hub, pas supposé.
  • Non vérifié : je n'ai pas joué le playbook. Le passage réel reste à faire, hors période d'activité.

Refs #50

🤖 Generated with Claude Code

Répond à **« qu'est-ce qui nous empêche d'upgrade des deux côtés ? »** — et la réponse est : **rien**. Personne n'avait décidé de rester en retard ; c'est une configuration qui l'imposait en silence. Ferme la moitié « versions divergentes » de #50. ## Le défaut Le playbook déploie `gitea/act_runner:**latest**` avec **`pull: missing`** : la pire combinaison possible — un tag **flottant** qui n'est **jamais rafraîchi**. `pull: missing` ne tire l'image que si elle est **absente** ; les deux hôtes en ayant déjà une sous ce tag, chacun garde ce que « latest » voulait dire **le jour de son premier pull**. ``` pi1 : sha256:7bdc8d31… → act_runner v0.3.1 pi3 : sha256:0f65fa10… → act_runner v0.2.13 ``` Deux machines censées être interchangeables, **trois versions mineures d'écart**. Effets mesurés : - le **même** job, sur la **même** image de CI : **511 s sur pi1**, **397 s sur pi3** — **114 s** imputables à la machine ; - pi3 (v0.2.13) a mal lu la définition d'un job dont il dépendait : `'runs-on' key not defined`, puis `No steps found`. ## Le correctif Une variable dans `inventory/group_vars/all/gitea.yml`, et le playbook la consomme : ```yaml gitea_runner_version: "0.3.1" ``` ⚠ **`pull: missing` redevient correct** avec un tag épinglé : changer la version change le tag, donc l'image est absente, donc elle est tirée. Pas besoin de `pull: always`, qui interrogerait le registre à chaque passage pour rien. ## Deux choix que je veux exposer plutôt que subir **1. Pourquoi pas `latest` + `pull: always` ?** Parce que **`latest` vaut aujourd'hui `0.6.1`** (Docker Hub, 30/04/2026) — 3 à 4 versions mineures devant tout ce qui est éprouvé ici. Le runner exécute **toute la CI de la forge** : une montée *subie*, non datée et non choisie s'y paie cher. On épingle, et on monte délibérément. **2. Pourquoi `0.3.1` et pas `0.6.1` ?** Parce que **0.3.1 est la version que pi1 exécute déjà avec succès** sur cette forge. Ce changement aligne donc **pi3 vers le haut, sur du prouvé**, sans saut de quatre versions sur le composant le plus critique. Passer ensuite à 0.6.1 devient une modification d'**une ligne**, datée et reculable — c'est tout l'intérêt de la variable. Si tu préfères viser 0.6.1 directement, c'est défendable — mais je recommande alors de le faire **sur pi3 d'abord** (il ne porte pas le control-plane k3s), d'observer quelques runs, puis pi1. ## ⚠ À savoir avant de jouer le playbook `03_cicd.yml` recrée les conteneurs de runner (`loop: [absent, present]`) : **il tue les jobs en vol**, qui deviennent `failure` avec leurs journaux perdus. Vérifier qu'aucun run n'est `queued` ni `in_progress` **juste avant** — et se rappeler qu'**un merge est un déclencheur**, donc que « plus rien ne tourne » se vérifie *après* le dernier merge. Ici, l'effet sera **une recréation sur les deux hôtes** (le tag change des deux côtés), donc une re-registration des deux runners. ## Vérifications - ✅ `03_cicd.yml` parse ; `image` et `pull` relus depuis le YAML chargé (`gitea/act_runner:{{ gitea_runner_version }}`, `pull: missing`). - ✅ La variable se charge bien depuis `group_vars/all/gitea.yml`. - ✅ Versions constatées **dans les conteneurs** (`act_runner --version`) et digests d'images relevés sur les deux hôtes — pas déduits. - ✅ `latest` = 0.6.1 vérifié sur Docker Hub, pas supposé. - **Non vérifié** : je n'ai **pas** joué le playbook. Le passage réel reste à faire, hors période d'activité. Refs #50 🤖 Generated with [Claude Code](https://claude.com/claude-code)
arcodange added 1 commit 2026-07-30 08:55:16 +02:00
fix(cicd) — épingler la version du runner : latest + pull: missing ne rafraîchit JAMAIS 48e3d6827c 
Réponse à « qu'est-ce qui nous empêche d'upgrade des deux côtés ? » : rien.
Le playbook déployait `gitea/act_runner:latest` avec `pull: missing`, c'est-à-dire
la pire combinaison possible — un tag FLOTTANT qui n'est JAMAIS rafraîchi. Chaque
hôte garde donc ce que « latest » voulait dire le jour de son premier pull :

  pi1 : sha256:7bdc8d31…  →  v0.3.1
  pi3 : sha256:0f65fa10…  →  v0.2.13

Deux machines censées être équivalentes, deux versions à trois mineures d'écart.
Effets mesurés : le MÊME job, sur la MÊME image de CI, met 511 s sur pi1 et
397 s sur pi3 (114 s d'écart imputables à la machine) ; et pi3 a mal lu la
définition d'un job dont il dépendait (« 'runs-on' key not defined », puis
« No steps found »).

⚠ POURQUOI PAS `latest` + `pull: always`. `latest` vaut aujourd'hui **0.6.1**
(Docker Hub, 30/04/2026), soit 3 à 4 versions mineures devant tout ce qui est
éprouvé ici. Le runner exécute TOUTE la CI de la forge : une montée subie, non
datée et non choisie s'y paie cher. On épingle donc, et on monte délibérément.

⚠ POURQUOI 0.3.1 ET PAS 0.6.1. 0.3.1 est la version que pi1 exécute DÉJÀ avec
succès sur cette forge. Ce changement aligne donc pi3 VERS LE HAUT, sur du
prouvé, sans saut de quatre versions. Passer ensuite à 0.6.1 devient une
modification d'UNE ligne, datée et reculable — c'est tout l'intérêt de la
variable.

⚠ Et `pull: missing` redevient CORRECT avec un tag épinglé : changer la version
change le tag, donc l'image est absente, donc elle est tirée. Aucun besoin de
`pull: always`, qui interrogerait le registre à chaque passage pour rien.

⚠ NE PAS jouer ce playbook pendant qu'une CI tourne : il recrée les conteneurs
de runner et TUE les jobs en vol (journaux perdus). Vérifier `list_runs` avant —
et se rappeler qu'un merge est un déclencheur.

Refs arcodange-org/factory#50

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
arcodange added 1 commit 2026-07-30 09:03:46 +02:00
feat(cicd) — Gitea 1.27.1 et Gitea Runner 2.3.0 : l'image du runner a CHANGÉ DE NOM 6bb27b0e5c 
⚠ CORRIGE LE PREMIER JET DE CETTE BRANCHE, qui épinglait `gitea/act_runner:0.3.1`.

`gitea/act_runner` est GELÉE à 0.6.1. Le successeur officiel est `gitea/runner`
(binaire renommé `act_runner` → `gitea-runner`), aujourd'hui en **2.3.0**.
Épingler l'ancien nom nous aurait enfermés dans une image morte — trouvé grâce
aux notes de version de Gitea 1.27 signalées par le fondateur.

VÉRIFIÉ AVANT DE BASCULER — c'est un remplacement DIRECT pour ce compose :
  • entrypoint identique : /sbin/tini -- run.sh
  • mêmes variables lues : CONFIG_FILE, GITEA_INSTANCE_URL,
    GITEA_RUNNER_{REGISTRATION_TOKEN,NAME,LABELS}
  • config.yaml compatible : capacity, labels, cache.*, container.force_pull,
    options, valid_volumes, host.workdir_parent — AUCUNE clé utilisée ici n'a
    disparu (comparé au `gitea-runner generate-config` de la 2.3.0)

La 2.3.0 apporte en prime des réglages qui parlent à nos pannes connues :
`health_check.min_free_disk_space_mb` (les images de runner supprimées quand le
disque se remplit, ADR 20260407) et `state_report_interval` (les tâches tuées en
zombie faute de rapport, factory#50).

GITEA 1.25.5 → 1.27.1 : deux versions mineures, migrations de base
IRRÉVERSIBLES. Sauvegardes du jour VÉRIFIÉES avant, pas supposées :
  /mnt/backups/postgres/backup_20260730.sql.gz  13 Mo, gzip -t OK,
      contient « CREATE DATABASE gitea » (pg_dumpall)
  /mnt/backups/gitea/backup_20260730.gitea.gz   1,7 Go, gzip -t OK
⚠ Le backup Gitea utilise `gitea dump --skip-db` : il ne contient PAS la base.
C'est le dump postgres qui la porte — les deux sont nécessaires.

Changements cassants de 1.27 et leur portée ici, vérifiée :
  • workflows réutilisables externes retirés → AUCUN dans front, kadans-api,
    factory (contrôlé programmatiquement, `uses:` au niveau job)
  • nonce CSP pour scripts inline → concerne les templates personnalisés, nous
    n'en avons pas
  • X-Content-Type-Options: nosniff par défaut

Refs arcodange-org/factory#50

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
arcodange merged commit 5ad6601c01 into main 2026-07-30 09:10:59 +02:00
arcodange deleted branch arcodange/runner-version-epinglee 2026-07-30 09:11:00 +02:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
arcodange
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: arcodange-org/factory#51