arcodangeandClaude Opus 5
e84383ee34
Le rôle gitea_repo ne savait viser qu'un propriétaire : l'organisation, des deux côtés à la fois. Les dépôts qui vivent sous le compte personnel `arcodange` ne pouvaient donc pas sortir du homelab — ni être balayés par gitea_sync, qui n'interroge que /orgs/<org>/repos. Trois séparations, toutes rétrocompatibles (les défauts reconduisent le comportement org-vers-org des dix dépôts déjà en miroir) : - le propriétaire côté Gitea (`gitea_repo_owner`) n'est plus le même objet que celui d'en face (`github_owner`, `gitlab_owner`) ; - un compte personnel n'est pas une organisation : GitHub ne crée pas le dépôt au même endroit, d'où `github_owner_is_org` qui route vers POST /user/repos ; - GitLab devient facultatif (`gitea_mirror_gitlab`). Il ne l'était pas : sa création attendait un 201 sans ignore_errors, si bien qu'un échec GitLab avortait l'itération — y compris la moitié GitHub, qui n'y était pour rien. Deux défauts corrigés au passage, tous deux silencieux : - les trois listages de gitea_sync ne paginaient pas (30 chez GitHub, 20 chez GitLab). Sous la taille d'une page tout va bien ; au-delà, la différence entre forges désigne de FAUX dépôts manquants et le rôle les « répare » ; - la migration entrante posait `repo_owner: github_organization` pour désigner le propriétaire DANS Gitea. Et un piège découvert en exécutant : un dépôt GitHub créé vide adopte comme branche par défaut la PREMIÈRE branche que le miroir lui pousse — `kadans` a atterri sur `arcodange/adr-ddd-front`. Le rôle réaligne désormais sur la branche par défaut de Gitea ; le miroir étant asynchrone, l'alignement échoue au run qui crée le dépôt et réussit au suivant, d'où le failed_when permissif. Ce qui sort du homelab reste un CHOIX : playbooks/07_mirrors.yml parcourt une liste explicite et relue (`gitea_mirrored_repos`) plutôt que la différence automatique entre forges, qui recréerait un dépôt supprimé exprès. 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.
🏹💻🪽