gitea_repo ne savait viser qu'un propriétaire, le même des deux côtés : l'organisation. Les dépôts qui vivent sous le compte personnel arcodange — kadans, kadans-api, kadans-dossier, kadans-jobs, video_analysis — ne pouvaient donc pas sortir du homelab. gitea_sync ne les voyait pas davantage : il n'interroge que /orgs/<org>/repos.
Trois séparations, rétrocompatibles
Les défauts reconduisent le comportement org-vers-org : les dix dépôts déjà en miroir ne bougent pas.
Variable
Défaut
Ce qu'elle sépare
gitea_repo_owner
gitea_organization
Le propriétaire côté Gitea n'est plus le même objet que celui d'en face
github_owner / gitlab_owner
github_organization / gitlab_root_group
Le propriétaire par forge
github_owner_is_org
true
false route la création vers POST /user/repos — un compte personnel n'a pas d'endpoint /orgs/<nom>/repos
gitea_mirror_github / gitea_mirror_gitlab
true
Éteindre une forge
GitLab n'était pas facultatif : 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 silencieux corrigés au passage
Les trois listages de gitea_sync ne paginaient pas (30 par défaut chez GitHub, 20 chez GitLab). Sous la taille d'une page tout va bien — on est à 25 dépôts Gitea, donc au bord. 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 là où la ligne désigne le propriétaire dans Gitea.
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, kadans-api sur arcodange/ouvrir-porte-google (corrigés à la main). 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: false plutôt qu'un blocage.
Ce qui sort du homelab reste un choix
playbooks/07_mirrors.yml parcourt une liste explicite et relue (gitea_mirrored_repos, dans l'inventaire) plutôt que la différence automatique entre forges : repos_incomplete = all − common ne dit pas pourquoi un dépôt manque, et recréerait un dépôt supprimé exprès. gitea_sync reste disponible, et sait maintenant balayer un compte personnel (gitea_sync_owner_is_org: false).
uv run ansible-playbook -i ansible/arcodange/factory/inventory \
ansible/arcodange/factory/playbooks/07_mirrors.yml
État réel au 2026-07-27
Les cinq miroirs sont déjà posés et vérifiés (dépôts GitHub privés, 8 h + sync_on_commit, première synchro déclenchée) — le main de github.com/arcodange/kadans est bien 072a8a5. Ce PR met le code du dépôt au niveau de ce qui tourne.
⚠ Moitié GitLab non exécutée : gitlab_personal_namespace_id est laissé à ~ faute d'accès au jeton GitLab (il ne vit que dans gitea_vault.yml chiffré). Le code la gère ; il reste à renseigner l'ID du namespace arcodange sur gitlab.com puis relancer. En attendant : -e gitea_mirror_gitlab=false.
⚠ Les miroirs posés portent comme mot de passe le jeton du CLI gh, faute d'accès au github_api_token du vault. Fonctionnel, mais à normaliser : supprimer le miroir puis relancer le playbook avec le vault.
Vérifications
ansible-playbook --syntax-check vert sur 07_mirrors.yml
Les 5 miroirs interrogés dans Gitea après coup : remote_address, interval=8h0m0s, sync_on_commit=true, last_update renseigné
Contenu confirmé côté GitHub : 25 branches sur kadans, main = 072a8a5
## Ce qui manquait
`gitea_repo` ne savait viser qu'**un** propriétaire, le même des deux côtés : l'organisation. Les dépôts qui vivent sous le compte personnel `arcodange` — `kadans`, `kadans-api`, `kadans-dossier`, `kadans-jobs`, `video_analysis` — ne pouvaient donc pas sortir du homelab. `gitea_sync` ne les voyait pas davantage : il n'interroge que `/orgs/<org>/repos`.
## Trois séparations, rétrocompatibles
Les défauts reconduisent le comportement org-vers-org : les **dix dépôts déjà en miroir ne bougent pas**.
| Variable | Défaut | Ce qu'elle sépare |
| --- | --- | --- |
| `gitea_repo_owner` | `gitea_organization` | Le propriétaire côté Gitea n'est plus le même objet que celui d'en face |
| `github_owner` / `gitlab_owner` | `github_organization` / `gitlab_root_group` | Le propriétaire par forge |
| `github_owner_is_org` | `true` | `false` route la création vers `POST /user/repos` — un compte personnel n'a pas d'endpoint `/orgs/<nom>/repos` |
| `gitea_mirror_github` / `gitea_mirror_gitlab` | `true` | Éteindre une forge |
**GitLab n'était pas facultatif** : 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 silencieux corrigés au passage
- **Les trois listages de `gitea_sync` ne paginaient pas** (30 par défaut chez GitHub, 20 chez GitLab). Sous la taille d'une page tout va bien — on est à 25 dépôts Gitea, donc au bord. 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` là où la ligne désigne le propriétaire **dans Gitea**.
## 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`, `kadans-api` sur `arcodange/ouvrir-porte-google` (corrigés à la main). 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: false` plutôt qu'un blocage.
## Ce qui sort du homelab reste un choix
`playbooks/07_mirrors.yml` parcourt une **liste explicite et relue** (`gitea_mirrored_repos`, dans l'inventaire) plutôt que la différence automatique entre forges : `repos_incomplete = all − common` ne dit pas *pourquoi* un dépôt manque, et recréerait un dépôt supprimé exprès. `gitea_sync` reste disponible, et sait maintenant balayer un compte personnel (`gitea_sync_owner_is_org: false`).
```sh
uv run ansible-playbook -i ansible/arcodange/factory/inventory \
ansible/arcodange/factory/playbooks/07_mirrors.yml
```
## État réel au 2026-07-27
Les cinq miroirs sont **déjà posés et vérifiés** (dépôts GitHub **privés**, 8 h + `sync_on_commit`, première synchro déclenchée) — le `main` de `github.com/arcodange/kadans` est bien `072a8a5`. Ce PR met le code du dépôt au niveau de ce qui tourne.
⚠ **Moitié GitLab non exécutée** : `gitlab_personal_namespace_id` est laissé à `~` faute d'accès au jeton GitLab (il ne vit que dans `gitea_vault.yml` chiffré). Le code la gère ; il reste à renseigner l'ID du namespace `arcodange` sur gitlab.com puis relancer. En attendant : `-e gitea_mirror_gitlab=false`.
⚠ Les miroirs posés portent comme mot de passe le jeton du CLI `gh`, faute d'accès au `github_api_token` du vault. Fonctionnel, mais à normaliser : supprimer le miroir puis relancer le playbook avec le vault.
## Vérifications
- `ansible-playbook --syntax-check` vert sur `07_mirrors.yml`
- Les 5 miroirs interrogés dans Gitea après coup : `remote_address`, `interval=8h0m0s`, `sync_on_commit=true`, `last_update` renseigné
- Contenu confirmé côté GitHub : 25 branches sur `kadans`, `main` = `072a8a5`
🤖 Generated with [Claude Code](https://claude.com/claude-code)
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]>
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.
Ce qui manquait
gitea_repone savait viser qu'un propriétaire, le même des deux côtés : l'organisation. Les dépôts qui vivent sous le compte personnelarcodange—kadans,kadans-api,kadans-dossier,kadans-jobs,video_analysis— ne pouvaient donc pas sortir du homelab.gitea_syncne les voyait pas davantage : il n'interroge que/orgs/<org>/repos.Trois séparations, rétrocompatibles
Les défauts reconduisent le comportement org-vers-org : les dix dépôts déjà en miroir ne bougent pas.
gitea_repo_ownergitea_organizationgithub_owner/gitlab_ownergithub_organization/gitlab_root_groupgithub_owner_is_orgtruefalseroute la création versPOST /user/repos— un compte personnel n'a pas d'endpoint/orgs/<nom>/reposgitea_mirror_github/gitea_mirror_gitlabtrueGitLab n'était pas facultatif : sa création attendait un
201sansignore_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 silencieux corrigés au passage
gitea_syncne paginaient pas (30 par défaut chez GitHub, 20 chez GitLab). Sous la taille d'une page tout va bien — on est à 25 dépôts Gitea, donc au bord. Au-delà, la différence entre forges désigne de faux dépôts manquants, et le rôle les « répare ».repo_owner: github_organizationlà où la ligne désigne le propriétaire dans Gitea.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.
kadansa atterri surarcodange/adr-ddd-front,kadans-apisurarcodange/ouvrir-porte-google(corrigés à la main). 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ù lefailed_when: falseplutôt qu'un blocage.Ce qui sort du homelab reste un choix
playbooks/07_mirrors.ymlparcourt une liste explicite et relue (gitea_mirrored_repos, dans l'inventaire) plutôt que la différence automatique entre forges :repos_incomplete = all − commonne dit pas pourquoi un dépôt manque, et recréerait un dépôt supprimé exprès.gitea_syncreste disponible, et sait maintenant balayer un compte personnel (gitea_sync_owner_is_org: false).État réel au 2026-07-27
Les cinq miroirs sont déjà posés et vérifiés (dépôts GitHub privés, 8 h +
sync_on_commit, première synchro déclenchée) — lemaindegithub.com/arcodange/kadansest bien072a8a5. Ce PR met le code du dépôt au niveau de ce qui tourne.⚠ Moitié GitLab non exécutée :
gitlab_personal_namespace_idest laissé à~faute d'accès au jeton GitLab (il ne vit que dansgitea_vault.ymlchiffré). Le code la gère ; il reste à renseigner l'ID du namespacearcodangesur gitlab.com puis relancer. En attendant :-e gitea_mirror_gitlab=false.⚠ Les miroirs posés portent comme mot de passe le jeton du CLI
gh, faute d'accès augithub_api_tokendu vault. Fonctionnel, mais à normaliser : supprimer le miroir puis relancer le playbook avec le vault.Vérifications
ansible-playbook --syntax-checkvert sur07_mirrors.ymlremote_address,interval=8h0m0s,sync_on_commit=true,last_updaterenseignékadans,main=072a8a5🤖 Generated with Claude Code