CI BotandClaude Opus 5
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 Factory
%%{init: { 'logLevel': 'debug', 'theme': 'base', 'rough':true } }%%
flowchart
prepare_hd>HD setup]
prepare_pg>PG Setup]
prepare_gitea>Gitea Setup]
origin_repo[[original repositories]]
github_repo_m[[gitea mirrors]]
gitlab_repo_m[[gitea mirrors]]
origin_repo -. mirrored .->gitlab_repo_m
origin_repo -. mirrored .->github_repo_m
tofu.state -. manages providers/go-gitea .- origin_repo
tofu.state -. manages providers/gitlabhq/gitlab .- gitlab_repo_m
tofu.state -. manages providers/integrations/github .- github_repo_m
subgraph Home
subgraph pi1
runner[/gitea runners\]
subgraph small HD
backup_data
end
end
subgraph pi2
PG[(Postgres)]
subgraph Gitea
origin_repo
end
subgraph HD
PG_data
Gitea_data
end
end
subgraph pi3
subgraph ai
ollama
end
end
subgraph "master (macbook pro)"
ansible{{ansible control-node}}
tofu{{opentofu control-node}}
subgraph ansible_scripts
direction TB
prepare_hd --> prepare_pg --> prepare_gitea
end
end
end
subgraph Internet
subgraph Gitlab
subgraph Group Arcodange
gitlab_repo_m
end
end
subgraph Github
subgraph Organization Arcodange
github_repo_m
end
end
subgraph GCP
subgraph project arcodange
subgraph gs://arcodange-tf
tofu.state
end
end
end
end
tofu == plan/apply ==> tofu.state
ansible == deploy ==> HD
ansible == deploy ==> PG
ansible == deploy ==> Gitea
ansible --- ansible_scripts
classDef done fill:gold,stroke:indigo,stroke-width:4px,color:blue;
class prepare_hd,nodeId2 done;
Documentation
- 📚
doc/— ADR (décisions d'architecture) + runbooks. - 🚀 Runbook : mettre en service une nouvelle application web — dépôt Gitea, base de données, Vault, chart Helm, Terraform, CI, ArgoCD.
🏹💻🪽