Como corrigir o erro EINTEGRITY ao implantar um Aplicativo de Múltiplos Objetivos (MTA) na SAP Cloud Platform Cloud Foundry

Se estás a usar o NodeJS no teu projeto (e é difícil não o fazer), é possível que te encontres preso no inferno do EINTEGRITY. O que quero dizer com isto?

Quando acontece:

Se estás a implementar uma Aplicação de Múltiplos Objetivos (MTA) na SAP Cloud Platform Cloud Foundry, é possível que falhe se houver uma discrepância nos ficheiros que estás a enviar como parte do teu projeto e a tentativa do sistema de extrair ficheiros dependentes adicionais durante a implementação. Isto pode ocorrer com implementações completas onde todo o projeto é comprimido num ficheiro .mtar, ou implementações parciais de módulos NodeJS individuais (incluindo o app-router e os módulos de base de dados HDI, que são aplicações NodeJS especializadas).

Como saber que está a acontecer:

Geralmente, verás que o módulo falha (ao realizar um push) ou que a implementação completa tentará iniciar o módulo 3 vezes antes de desistir. Observa a saída e encontra qual módulo está a falhar. A saída padrão não te dará informação suficiente para resolver isto. Precisas inspecionar os registos do módulo em si.

cf logs failing-module --recent

Desloca-te para trás na saída dos registos procurando a mensagem "npm ERR! code EINTEGRITY". Aqui tens um exemplo da saída.

        2020-07-06T19:40:39.05-0400 [STG/0] OUT --> Building dependencies
        2020-07-06T19:40:39.05-0400 [STG/0] OUT Installing node modules (package.json + package-lock.json)
        2020-07-06T19:41:00.45-0400 [STG/0] OUT npm ERR! code EINTEGRITY
        ...
    

Por que está a acontecer:

Quando os teus ficheiros NodeJS estão a ser preparados para uma implementação, a ferramenta de empacotamento fará um "npm install --production" em cada módulo de NodeJS para criar uma pasta node_modules com todas as dependências (e dependências de dependências) listadas no ficheiro package.json e um ficheiro package-lock.json que esteja sincronizado com ele. Todos os ficheiros são comprimidos no ficheiro .mtar e são enviados para a implementação.

Se executares "npm install" dentro de um único módulo e fizeres manualmente "cf push", o efeito é semelhante, apenas fizeste a parte do "npm install" tu mesmo.

Quando o módulo é recebido pela plataforma na nuvem e implementado, o pacote de compilação de NodeJS analisará o que foi enviado e procurará se são necessárias dependências adicionais que não foram enviadas.

AQUI É ONDE OCORRE O PROBLEMA!

Se for determinado (e não tenho a certeza do que desencadeia isto) que o pacote de compilação precisa de verificar as dependências, ele lerá o ficheiro package-lock.json que enviaste e fará uma verificação de integridade gerando um checksum no pacote (o checksum but got ) que enviaste em node_modules OU um que determinou que precisava de descarregar do repositório de pacotes de onde quer extrair e comparará com o que estava listado no ficheiro package-lock.json (o checksum wanted ). Se encontrar que não coincidem, obterás o erro "npm ERR! code EINTEGRITY" e a implementação/push falhará.

O que podes fazer em relação a isto?

Parece que a razão pela qual isto acontece deve-se a algum problema que ocorre quando o pacote é publicado no repositório. O menor erro resultará numa discrepância no checksum.

1. Espera que o proprietário do pacote note o problema e republique o pacote para que o checksum seja correto.


2. Se estás a enviar manualmente o módulo único, podes editar o package-lock.json, encontrar o pacote e substituir o checksum ( but got checksum pelo wanted checksum) e guardar o ficheiro package-lock.json e reenviar o módulo.

Mas, e se estiveres a tentar implementar inicialmente toda a aplicação e a ferramenta de empacotamento continuar a executar "npm install" e a colocar o que pensa ser o checksum correto no ficheiro package-lock.json antes de o levar durante a implementação (Caso #2)? Poderias descomprimir o ficheiro mtar, descomprimir o módulo problemático, corrigir o ficheiro package-lock.json, recomprimir e depois implementar o ficheiro mtar, mas que dor isso é.

E se tiveres um prazo (ou simplesmente quiseres avançar) e não puderes esperar que o pacote seja corrigido em