3.3 KiB

Raw Blame History

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 :

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

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

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)

# 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.

3.3 KiB Raw Blame History