Voici sur quoi je tombe en faisant un npm publish !

Si vous êtes sûr de votre procédure, et que vous utilisez un reverse-proxy NGINX devant votre gitlab, alors vérifiez cela :

Vous avez un slash à la fin de votre proxy_pass sous nginx ? Retirez-le !

Analyses

J’utilise un serveur GITLAB pour gérer le dépots des NPM (il sait aussi faire GO, PIP, Nugget, Docker…). C’est très pratique la pour CD-CI puisqu’on n’a pas à gérer des credentials, des hooks par rapport à un système de CI/CD dédié (jenkins).

Ce GITLAB est configuré en HTTP (son nginx est désactivé), et une autre machine fait reverse proxy HTTPS en frontale. La partie SSH+GIT est lié à une autre ip dédiée.

Après avoir vérifié et refait la procédure NPM avec GITLAB 20 fois, je finis par tester avec l’instance en ligne gitlab.com : pas de problème, ça fonctionne.

Je teste sur une autre instance gitlab auto-hébergée : pas de problème non plus !

Je compare les configs, aucune différence notable.

Analyse des logs gitlab entre un serveur qui fonctionne et un autre qui fonctionne pas, je m’aperçoit que l’URL a une partie différente : « %2f » sur l’un et « / » sur l’autre.

Je compare les configs NGINX, aucune différence notable.

Je suspecte tout de même le reverse proxy de modifier ma requête. Je lance donc un tcpdump pour le vérifier et constate que ma requête reçue par nginx :

PUT https://gitlab.qth.fr/api/v4/projects/8/packages/npm/@test%2fapi

est renvoyée avec une url modifiée :

PUT https://gitlab.qth.fr/api/v4/projects/8/packages/npm/@test/api

Du coup, effectivement, cette URL n’existe pas sous gitlab, et ce dernier renvoi un 404.

A noter que si vous n’avez pas l’autorisation ou que le scope (ici @test) est pas correcte, vous obtiendrez une erreur 400 de la part de GITLAB. (ou 403 si vous tentez d’écraser une version déjà présente), mais pas 404.

A savoir : gitlab redirige par defaut vos demandes vers le registry npmjs officiel si il ne connait pas le package. Cela peut etre assez pratique pour gérer plus globale le registry à utiliser sur un poste de dev ou un serveur puisqu'il n'y en a qu'un. (et non plus un par scope, avec son credential à prévoir).

Tags: , , , ,