Winston: Impossible d'installer sur docker après 3.3.0/3.3.1

Même problème ici, mais pas seulement dans docker. Je ne peux pas npm installer mon projet à cause de cette dépendance :

npm ERR! Error while executing:
npm ERR! /usr/local/bin/git ls-remote -h -t ssh://[email protected]/DABH/diagnostics.git
npm ERR! 
npm ERR! ssh: connect to host github.com port 22: Connection timed out
npm ERR! fatal: Could not read from remote repository.
npm ERR! 
npm ERR! Please make sure you have the correct access rights
npm ERR! and the repository exists.
npm ERR! 
npm ERR! exited with error code: 128

Je me demande si le problème est qu'il essaie d'atteindre le dep via ssh au lieu de https.

L'un de vous peut-il essayer de modifier le package.json afin que le diagnostics dep soit
git+https://github.com/DABH/diagnostics.git
? Cela devrait le forcer à utiliser https mais je veux être sûr à 100% que cela résoudra votre problème avant de faire une autre version hotifx. Merci!

J'ai le même problème lors de l'installation via docker.
J'ai essayé de modifier le package.json, mais je ne suis pas sûr de le faire correctement.
dans node_modules/winston/package.json j'ai changé : "diagnostics": " github:DABH/diagnostics#master ",
dans : "diagnostics": "git+ https://github.com/DABH/diagnostics.git ",

Cela ne fonctionne pas, mais je m'attendais à devoir changer une dépendance se terminant par "diagnostics.git" mais je n'ai pas trouvé cela dans le projet.

edit : j'utilise ' node:12.10.0-alpine ' comme image de base pour docker

J'ai enquêté sur le problème et il semble que le problème provienne d'une image docker basée sur les Alpes. Même le Dockerfile suivant ne parvient pas à se construire, quelle que soit la version du nœud.

FROM node:14-alpine

RUN npm install git+https://github.com/lodash/lodash

Ah, parce que le dep vient de github, vous avez besoin de git...

FROM node:14-alpine

RUN apk update && apk upgrade && \
    apk add --no-cache bash git openssh

RUN npm install git+https://github.com/lodash/lodash

Je comprends que ce n'est pas une bonne solution. L'alternative est que je dois publier mon fork diagnostics sur NPM, mais ce paquet est déjà sur NPM, donc je suppose que je devrais changer le nom de mon référentiel ou quelque chose pour que je puisse publier de manière unique. Tous les conseils sont les bienvenus, sinon je regarderai cela plus tard dans la journée.

Oui, j'ai trouvé la même solution. (Je ne pouvais même pas imaginer que git n'est pas livré sur alpine..) Je suis d'accord avec cette solution.

Le problème n'était pas avec Winston donc je ferme ça. Merci pour l'aide!

bonjour, pareil de mon côté, quelques logs :

https://travis-ci.org/github/weareopensource/Node/builds/700773943
https://hub.docker.com/repository/registry-1.docker.io/weareopensource/node/builds/cd59b608-6976-48c2-8765-e7076afb971f

Merci, voir mon message plus haut ^^

@DABH @Kivol

hum, oui, je comprends, merci :)

Pour moi, la solution reste temporaire et le problème ne doit pas être clos.

Un package NPM ne devrait pas nécessiter git pour l'installation mais uniquement npm. Si vous utilisez un FORK d'un autre package car celui-ci ne correspond pas à votre besoin. Je pense que ce FORK doit être intégré à la source ou devenir un projet maintenu pour Winston et donc publié comme vous l'avez suggéré. Il serait assez étrange d'imposer l'installation de git ou de tout autre outil pour l'installation d'un package npm, pour des centaines d'image docker. Les images et le processus doivent être aussi légers que possible

Salut, je veux juste exprimer que git ne devrait pas être un dep pour winstonjs. J'espère que cela pourra être résolu. Nous avons quelques centaines d'images de menu fixe et je ne pense pas que les modifier toutes serait très idéal. Et je suis sûr que beaucoup d'entre nous ressentiraient la même chose. :)

Si 3.3.x a vraiment un tel changement de rupture, nous devrions le déplacer vers 4.x à la place.

@DABH @Kivol

Deuxièmement, les commentaires ci-dessus à propos de ce changement étant un changement de rupture. Nous avons des images de docker alpin en production qui vont casser à cause de cela.

Si cela est nécessaire, alors prendrait en charge un changement 4.x.

Wow, celui-ci casse Internet... :)
Très étrange d'exiger git en effet.

J'ai le même problème pas dans une image docker mais dans mon réseau d'entreprise.

J'utilise l'artefact pour télécharger toutes les dépendances (npm et github ont été bloqués). Si vous utilisez votre fork, tous les projets sans accès public échoueront. L'impact le plus important concerne les entreprises ou les CI/CD à accès restreint.

De mon point de vue, si vous voulez conserver votre fork, vous devez être standard et créer un nouveau package npm et ne pas vous référer à un dépôt github.

Alors pourquoi ce ticket est-il toujours fermé ?

Même problème ici, merci de le corriger. Malheureusement, winston est installé en tant que module d'une sous-dépendance, nous ne pouvons donc pas modifier directement la version. Cela casse notre pipeline CI qui n'a pas accès au github public.

+1 pour ce problème, cela casse notre pipeline CI.
Veuillez annuler les modifications.

@Kivol s'il vous plaît rouvrez, installez git n'est pas une option pour plusieurs projets
surtout quand winston n'est pas une dépendance directe.

+1 aussi. Cela enfreint le principe de construction unique et brise les constructions pour nos consommateurs. Peut-être que revenir en arrière jusqu'à ce qu'il soit corrigé est une bonne option ici ?

Juste pour dire que je pense que les commentaires ci-dessus montrent clairement à quel point Winston est utilisé et dépend de nombreux projets. Donc, même si c'est pénible lorsque des problèmes surviennent - j'espère que je parle au nom de beaucoup - quand je dis que nous apprécions la contribution de Winston et de ses développeurs.

Pareil ici.
Deux points à ajouter :

1. ajouter des dépendances au travail CI/CD basé sur une image Alpine casse le concept et a un coût (pensez "_green dev_")
2. dans un environnement d'entreprise, nous ne pouvons pas modifier la configuration globale du réseau (si jamais nous le pouvions !) pour obtenir un seul package

Merci pour les commentaires actifs, veuillez patienter quelques heures pendant que nous essayons de déployer une meilleure solution (non dépendante de git) pour cela.

Tout, v3.3.2 a été publié, cela télécharge la dépendance bifurquée diagnostics de NPM et non de GitHub, donc cela devrait fonctionner pour vous. N'hésitez pas à confirmer ou infirmer. Merci!

Merci pour le correctif.