Salut à tous,
J’essaie de créer un flux de travail qui clone un dépôt lors de l’exécution d’un webhook.
Cependant, lorsque le nœud Git Clone s’exécute, il se bloque simplement sans aucun retour (erreur, journal ou résultat), et le dossier du dépôt spécifié ne se remplit pas non plus.
Un phénomène similaire se produit lorsque j’utilise le nœud « Read File(s) From Disk ». Lorsque je configure ce nœud pour lire un fichier spécifié, il se bloque également.
Quel est le message d’erreur (le cas échéant) ?
Veuillez partager votre flux de travail
(Sélectionnez les nœuds sur votre canevas et utilisez les raccourcis clavier CMD+C/CTRL+C et CMD+V/CTRL+V pour copier et coller le flux de travail.)
Salut @ewoud Bienvenue dans la communauté n8n
Un clone qui se fige sans erreur et sans dossier est presque toujours git en attente d’une invite qu’il ne peut pas afficher. À l’intérieur du conteneur, il n’y a pas de terminal, donc un dépôt privé demandant des identifiants, ou une URL SSH vous demandant d’accepter une clé d’hôte inconnue, bloque indéfiniment au lieu d’échouer. Définissez GIT_TERMINAL_PROMPT=0 sur le conteneur et relancez-le. Vous obtiendrez une véritable erreur en quelques secondes, qui vous indique de quel problème il s’agit.
L’arrêt du nœud de fichier mérite d’être traité comme un problème distinct. Vérifiez que le dossier est réellement monté en bind dans le conteneur et non pas seulement un chemin de partage UGOS, puisque le nœud voit le système de fichiers du conteneur et rien d’autre.
Salut @ewoud Bienvenue !
Les deux nœuds accèdent au chemin avant de faire un vrai travail. Le nœud Git résout le chemin du référentiel avec realpath avant d’appeler git, et le nœud fichier exécute le glob avant d’ouvrir quoi que ce soit, donc aucun d’eux n’atteint l’opération que vous avez configurée. Un chemin qui manque, qui est inaccessible depuis le conteneur, ou qui se trouve en dehors du répertoire autorisé échoue immédiatement avec une erreur plutôt que de rester bloqué, donc un spinner qui ne se résout jamais et ne lève jamais d’erreur signifie que l’appel système de fichiers lui-même ne retourne pas.
Cela se produit lorsque le chemin se retrouve sur un montage qui est toujours attaché mais ne répond plus, ce qu’un dossier distant ou cloud sur le NAS fait une fois que sa connexion de secours tombe. Vérifiez le même chemin de l’intérieur du conteneur :
docker exec -it <your-n8n-container> ls -la /your/configured/path
Si cela reste bloqué aussi, le problème se trouve sous le montage et n8n ne peut que rester bloqué dessus. Pointez les deux nœuds vers un volume Docker simple à la place. En 2.x, le chemin doit également se trouver à l’intérieur de N8N_RESTRICT_FILE_ACCESS_TO, qui par défaut est maintenant ~/.n8n-files.
Les points ci-dessus mettent en évidence les deux raisons exactes pour lesquelles les nœuds Git Clone ou File se figent indéfiniment sans lancer d’erreur dans les instances Docker d’n8n :
Git attend les identifiants interactifs :
Lors du clonage via SSH ou HTTPS sans clés d’hôte pré-acceptées, Git se fige en attendant une saisie utilisateur. La définition de cette variable d’environnement force Git à échouer rapidement et à afficher le vrai message d’erreur :
GIT_TERMINAL_PROMPT=0
Montage réseau obsolète ou figé :
Si votre répertoire cible se trouve sur un partage réseau (NAS, SMB, NFS) qui s’est déconnecté, les I/O système se figent. Vérifiez si votre conteneur peut lire le chemin en exécutant :
docker exec -it <container_name> ls -la /path/to/target
Restrictions d’accès aux fichiers dans n8n v2.x+ :
Assurez-vous que le dossier de destination figure dans la liste blanche de vos variables d’environnement :
N8N_RESTRICT_FILE_ACCESS_TO=/path/to/target
Le test de ces trois éléments permettra de déterminer s’il s’agit d’un blocage de demande d’identifiants ou d’un problème de montage Docker.
