# GIT PUSH depuis le container mcp-nas

**Date** : 2026-06-15 (mise à jour 2026-07-08)
**Contexte** : git push Gitea depuis mcp-nas (container Docker sur NAS DS920+)

## Problème
`git push http://bolbol:PASSWORD@192.168.100.33:3232/...` → **timeout systématique**  
L'IP 192.168.100.33 est inaccessible depuis l'intérieur du container mcp-nas.

## Solution validée (si le binaire git est présent dans le container)
Utiliser **172.17.0.1** (gateway Docker bridge) à la place :

```bash
cd /mnt/docker/<repo>
GIT_TERMINAL_PROMPT=0 git push http://bolbol:PASSWORD@172.17.0.1:3232/bolbol/<repo>.git main
```

## Vérifier l'accessibilité Gitea avant un push
```bash
curl -s --max-time 8 http://172.17.0.1:3232/api/v1/repos/bolbol/<repo> \
  -H "Authorization: basic $(echo -n 'bolbol:PASSWORD' | base64)" \
  -o /dev/null -w "%{http_code}"
# Doit retourner 200
```

## Règle générale réseau mcp-nas
| Depuis mcp-nas | À ne JAMAIS utiliser | À utiliser |
|---|---|---|
| Gitea | 192.168.100.33:3232 | 172.17.0.1:3232 |
| SSH NAS | 192.168.100.33:22222 | 172.17.0.1:22222 |
| NyoraNotes | 192.168.100.33:8787 | 172.17.0.1:8787 |
| n8n | 192.168.100.33:5678 | 172.17.0.1:5678 |

## Ce qui NE fonctionne PAS
- `192.168.100.33` depuis mcp-nas : timeout sur tous les ports
- `git push` sans `GIT_TERMINAL_PROMPT=0` peut bloquer en attente de saisie

---

## FALLBACK sans git (ajouté 2026-07-08)

**Constat** : certains containers mcp-nas n'ont pas le binaire `git` installé (`git: command not found`). Plutôt que d'installer le paquet, utiliser l'**API HTTP Gitea directement** — plus léger, zéro dépendance, un seul appel curl.

### Créer un nouveau fichier
```bash
CONTENT_B64=$(base64 -w0 chemin/local/fichier.md)
curl -s -X POST "http://172.17.0.1:3232/api/v1/repos/bolbol/<repo>/contents/<chemin/dans/repo>.md" \
  -H "Authorization: token <GITEA_TOKEN_NYORA|TT|PERSO>" \
  -H "Content-Type: application/json" \
  -d "{\"message\":\"<message commit>\",\"content\":\"${CONTENT_B64}\",\"branch\":\"main\"}"
```

### Mettre à jour un fichier existant (SHA requis)
```bash
# 1. Récupérer le sha courant
SHA=$(curl -s "http://172.17.0.1:3232/api/v1/repos/bolbol/<repo>/contents/<chemin>.md" \
  -H "Authorization: token <TOKEN>" | python3 -c "import json,sys; print(json.load(sys.stdin)['sha'])")

# 2. Push avec le sha
CONTENT_B64=$(base64 -w0 chemin/local/fichier.md)
curl -s -X PUT "http://172.17.0.1:3232/api/v1/repos/bolbol/<repo>/contents/<chemin>.md" \
  -H "Authorization: token <TOKEN>" \
  -H "Content-Type: application/json" \
  -d "{\"message\":\"<message commit>\",\"content\":\"${CONTENT_B64}\",\"sha\":\"${SHA}\",\"branch\":\"main\"}"
```

### Tokens par sphère
Dans `/volume1/docker/hermes-platform/.env` : `GITEA_TOKEN_TT`, `GITEA_TOKEN_NYORA`, `GITEA_TOKEN_PERSO`. Utiliser le token correspondant à la sphère du repo modifié.

### Quand l'utiliser
- **Oui** : push ponctuel d'un seul fichier (runbook, note, config simple), git absent, ou pour éviter d'installer un paquet pour une seule opération.
- **Non** : commits multi-fichiers, historique de merge complexe, besoin de `git log`/`git diff` local → rester sur git classique si le binaire est disponible.

### Gain
Aucune installation de paquet, un seul appel réseau, fonctionne identiquement pour les 3 sphères (Nyora/TT/Perso) en changeant simplement le token.