Agent utilisateur pour Gitea, messages d'erreur exploitables
build / Images Harbor (catalog-sync, Dockerfile.catalog-sync) (push) Successful in 9m45s
build / Garde-fou (push) Successful in 10m22s
build / Images Harbor (web, Dockerfile) (push) Successful in 13m6s

This commit is contained in:
hcornet committed 2026-09-11 12:50:27 +02:00
1 parent c411f2933d
commit 8559aca4d7
11 files changed
+338 -25

No files matched your search

+17
View File
@@ -103,6 +103,23 @@ Un jeton d'accès personnel sur le compte qui ouvrira les demandes de fusion, av
dépose le fichier YAML et ouvre une pull request — **jamais un push sur la branche
principale**. Tu relis dans Gitea avant de fusionner.
### Si la publication échoue en 403
Une protection placée devant Gitea — Cloudflare et son contrôle d'intégrité du navigateur,
par exemple — rejette les clients qui ne sont pas des navigateurs. Le symptôme est un
`HTTP 403 : error code: 1010`, et la requête n'atteint jamais Gitea.
La sortie consiste à joindre Gitea directement, sans passer par la protection :
```yaml
extra_hosts:
- "gitea.exemple.com:192.168.1.10"
```
Le nom d'hôte est inchangé, donc le certificat reste valide ; seul le chemin réseau change.
Alternative : pointer `ENCLUME_GITEA_URL` sur une adresse interne, au prix d'un certificat
qui ne correspondra plus.
## Ce qui n'est jamais stocké
Les macros marquées « mot de passe » sont vidées avant toute écriture en base : partage,