Winston: Não é possível instalar no docker após 3.3.0/3.3.1

Criado em 22 jun. 2020  ·  23Comentários  ·  Fonte: winstonjs/winston

npm ERR! path git
npm ERR! code ENOENT
npm ERR! errno ENOENT
npm ERR! syscall spawn git
npm ERR! enoent Error while executing:
npm ERR! enoent undefined ls-remote -h -t ssh://[email protected]/DABH/diagnostics.git
npm ERR! enoent
npm ERR! enoent
npm ERR! enoent spawn git ENOENT
npm ERR! enoent This is related to npm not being able to find a file.
npm ERR! enoent

Parece que isso está relacionado ao #1813 e ainda acontece ao tentar instalar no docker com o nodejs 12.

Comentários muito úteis

Tudo, v3.3.2 foi lançado, isso baixa a dependência bifurcada diagnostics do NPM e não do GitHub, então deve funcionar para você. Sinta-se à vontade para confirmar ou negar. Obrigado!

Todos 23 comentários

Mesmo problema aqui, mas não apenas no docker. Não consigo npm instalar meu projeto por causa dessa dependência:

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

Gostaria de saber se o problema é que ele está tentando alcançar o dep por ssh em vez de https.

Um de vocês pode tentar modificar o package.json do winston para que o diagnostics dep seja
git+https://github.com/DABH/diagnostics.git
? Isso deve forçá-lo a usar https, mas quero ter 100% de certeza de que resolve seu problema antes de fazer outro lançamento de hotifx. Obrigado!

Estou tendo o mesmo problema ao instalar através do docker.
Tentei modificar o package.json, mas não tenho certeza se estou fazendo certo.
em node_modules/winston/package.json alterei: "diagnostics": " github:DABH/diagnostics#master ",
em: "diagnostics": "git+ https://github.com/DABH/diagnostics.git ",

Isso não está funcionando, mas eu esperava precisar alterar uma dependência que terminasse com "diagnostics.git", mas não consegui encontrar isso no projeto.

edit: estou usando ' node:12.10.0-alpine ' como imagem base para o docker

Estive investigando sobre o problema e parece que o problema vem da imagem do docker baseada em alpine. Mesmo o seguinte Dockerfile falha ao compilar, independentemente da versão do nó.

FROM node:14-alpine

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

Ah, porque o dep está vindo do github, você precisa do 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

Eu entendo que não é uma ótima solução. A alternativa é que eu tenha que publicar meu fork diagnostics no NPM, mas esse pacote já está no NPM, então acho que precisaria alterar o nome do meu repositório ou algo assim para poder publicar exclusivamente. Qualquer dica é bem-vinda, mais vou dar uma olhada nisso ainda hoje.

Sim, eu encontrei a mesma solução. (Eu não poderia nem imaginar que o git não é enviado em alpine ..) Eu estou bem com essa solução.

O problema não era com o winston, então estou fechando isso. Obrigado pela ajuda!

Obrigado, veja meu post acima ^^

@DABH @Kivol

hum, sim, eu entendo, Thx :)

Para mim, a solução permanece temporária e o problema não deve ser encerrado.

Um pacote NPM não deve exigir git para instalação, mas apenas npm. Se você usar um FORK de outro pacote porque este não corresponde a sua necessidade. Acho que esse FORK deve ser integrado na fonte ou se tornar um projeto mantido para Winston e, portanto, publicado como você sugeriu. Seria muito estranho impor a instalação do git ou qualquer outra ferramenta para a instalação de um pacote npm, por centenas de imagens docker. As imagens e o processo devem ser o mais leves possível

Oi, eu só quero expressar que git não deve ser um dep para winstonjs. Espero que isso possa ser resolvido. Temos algumas centenas de imagens do docker e não acho que modificar todas elas seria o ideal. E tenho certeza que muitos de nós sentiríamos o mesmo. :)

Se o 3.3.x realmente tiver uma mudança tão importante, devemos movê-lo para o 4.x.

@DABH @Kivol

Segundo os comentários acima sobre essa mudança ser uma mudança de ruptura. Temos imagens alpine docker em produção que serão interrompidas devido a isso.

Se isso for necessário, então suportaria uma mudança 4.x.

Nossa, essa quebra a internet... :)
Muito estranho exigir o git de fato.

Eu tenho o mesmo problema não em uma imagem docker, mas na minha rede corporativa.

Eu uso artefato para baixar todas as dependências (npm e github foram bloqueados). Se você usar seu fork, todos os projetos sem acesso público falharão. O maior impacto é para empresas ou CI/CD com acesso restrito.

No meu ponto de vista, se você quiser manter seu fork, você precisa ser padrão e criar um novo pacote npm e não fazer referência a um repositório do github.

Então, por que esse ticket ainda está fechado?

Mesmo problema aqui, por favor corrija. Infelizmente o winston está instalado como um módulo de uma subdependência, então não podemos modificar diretamente a versão. Isso interrompe nosso pipeline de CI que não tem acesso ao github público.

+1 para este problema, isso interrompe nosso pipeline de CI.
Por favor, reverta as alterações.

@Kivol , por favor, abra novamente, instale o git não é uma opção para muitos e muitos projetos
especialmente quando winston não é dependência direta.

+1 também. Isso viola o princípio build once e quebra builds para nossos consumidores. Talvez reverter até que seja corrigido seja uma boa opção aqui?

Só para dizer que acho que os comentários acima mostram claramente o quanto o Winston é usado e dependendo de muitos projetos. Portanto, embora seja doloroso quando ocorrem problemas - espero falar por muitos - quando digo que valorizamos a contribuição que Winston e seus desenvolvedores fazem.

Mesmo aqui.
Dois pontos a acrescentar:

  1. adicionar dependências ao trabalho de CI/CD com base em uma imagem Alpine quebra o conceito e tem um custo (pense em "_green dev_")
  2. em um ambiente corporativo, não podemos alterar a configuração geral da rede (se é que podemos!) para obter apenas um pacote

Obrigado pelos comentários ativos, por favor, tenha paciência por algumas horas enquanto tentamos lançar uma solução melhor (não dependente do git) para isso.

Tudo, v3.3.2 foi lançado, isso baixa a dependência bifurcada diagnostics do NPM e não do GitHub, então deve funcionar para você. Sinta-se à vontade para confirmar ou negar. Obrigado!

Obrigado pela correção.

Esta página foi útil?
0 / 5 - 0 avaliações