I've got a mono-repo setup with lerna and yarn workspaces.
To build the docker images for servers in the project, I'm using verdaccio as a GitLab service.
In the build phase, I want to publish packages and when running the server I'm planing to install them from the verdaccio registry.
With GitLab CI services we can not pass config files to the service. (APMK)
Currently the error I'm having is, error with auth, since I'm trying to publish a scoped package.
Step 14/24 : RUN lerna publish from-package --yes --no-git-reset
---> Running in 9c2db92f90f0
info cli using local version of lerna
lerna notice cli v4.0.0
lerna notice FYI Unable to verify working tree, proceed at your own risk
lerna WARN Unable to determine published version, assuming "#scope/package-1" unpublished.
lerna WARN Unable to determine published version, assuming "#scope/package-2" unpublished.
Found 2 packages to publish:
- #scope/package-1 => 1.0.0
- #scope/package-2 => 1.0.0
lerna info auto-confirmed
lerna info publish Publishing packages to npm...
lerna notice Skipping all user and access validation due to third-party registry
lerna notice Make sure you're authenticated properly ¯\_(ツ)_/¯
lerna notice FYI Unable to set temporary gitHead property, it will be missing from registry metadata
lerna info lifecycle root#undefined~prepare: root#undefined
lerna WARN lifecycle root#undefined~prepare: cannot run in wd root#undefined husky install (wd=/home/app)
lerna http fetch PUT 401 http://verdaccio:4873/#scope%2fpackage-1 26ms
lerna ERR! E401 authorization required to publish package #scope/package-1
The command '/bin/sh -c lerna publish from-package --yes --no-git-reset' returned a non-zero code: 1
In the CI environment I can not run npm adduser since it's an interactive prompt. I tried few way to bypass is seems they doesn't work.
Some like
RUN npm adduser <<! \
auser \
'1234' \
user#domain.tld \
!
Can I create a user inside a Dockerfile or can I bypass auth for scoped packages?
Related
This is confusing so I apologize if I don't word this sufficiently well.
Essentially, I'm leveraging npm's --force flag to bypass a conflicting peer-dependency error with npm#8. Subsequent npm install s of the dependencies complete without any errors. When attempting to install dependencies via docker, however, the original error returns.
So, originally:
encounter error:
npm ERR! ERESOLVE could not resolve
...
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
bypass via npm install --force
subsequent npm installs work without issue in new local environments (e.g. clone into new dir, run npm install)
However, attempting to npm install or npm ci (npm ci ensures a lockfile already exists) in a docker build continues throws the original error:
npm ERR! ERESOLVE could not resolve
...
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
Which, to me, suggests the lockfile isn't being respected. But we know it exists because otherwise npm ci would error.
Does anyone have an idea as to why this might be the case?
Dockerfile I'm testing with:
# // Dockerfile
# ==== CONFIGURE =====
# Use a Node 16 base image
FROM node:16-alpine
# Set the working directory to /app inside the container
WORKDIR /app
# Copy app files
COPY package-lock.json .
RUN echo $(ls)
# ==== BUILD =====
# Install dependencies (npm ci makes sure the exact versions in the lockfile gets installed)
RUN npm ci
# Build the app
RUN npm run build
# ==== RUN =======
# Set the env to "production"
ENV NODE_ENV production
# Expose the port on which the app will be running (3000 is the default that `serve` uses)
EXPOSE 3000
# Start the app
CMD [ "npx", "serve", "build" ]
Local npm is v8.1, docker npm is v8.19. Seems they introduced a breaking change at some point between those two versions.
From official docs:
NOTE: If you create your package-lock.json file by running npm install with flags that can affect the shape of your dependency tree, such as --legacy-peer-deps or --install-links, you must provide the same flags to npm ci or you are likely to encounter errors. An easy way to do this is to run, for example, npm config set legacy-peer-deps=true --location=project and commit the .npmrc file to your repo.
I'm trying to define and build a docker container via a Dockerfile that is pulling in an npm dependency that is privately hosted in GCP Artifactory
The .npmrc file works for publishing the dep. But when the docker container runs npm install it struggles to access the private npm registry.
How do I grant a Dockerfile the permission to do an npm install where one of the dependancies is hosted on GCP's artifactory?
Inject the credentials? Copy them in? (doesn't seem safe)
I get an error like this:
---> Running in 058536ed8d33
npm ERR! code E403
npm ERR! 403 403 Forbidden - GET https://us-central1-npm.pkg.dev/<.....>
Permission "artifactregistry.repositories.downloadArtifacts" denied on resource "projects/<....>/locations/us-central1/repositories/<...>" (or it may not exist)
I'm trying to install randomstring package into Cypress container because my tests are using it.
Dockerfile:
FROM cypress/base:17.8.0
RUN npm install randomstring#1.2.2
RUN npm install cypress#7.0.0
COPY . /e2e
RUN npm cypress run
error output I'm getting:
1 error occurred:
* Status: The command '/bin/sh -c npm install randomstring#1.2.2 cypress#7.0.0' returned a non-zero code: 1, Code: 1
I'm aware that Cypress/base image comes with operating system and dependencies required in order to run Cypress but I'm not sure if npm is included.
What is the right way to install packages into Cypress container ?
Any particular reason to use base image?
Have you tried with cypress/included:7.0.0, which already has cypress + browsers installed.
Furthermore it's better to keep all your dependencies (randomstring included) in package.json file where they belong, copy it over and call npm install or npm ci.
Here are my files.
Here is I think the core of the problem.
Could not resolve dependency:
npm ERR! peer graphql#"^0.12.0 || ^0.13.0 || ^14.0.0" from graphql-middleware#4.0.2
docker-compose.yml
version: '3.7'
services:
apollo:
container_name: apollo
build:
context: .
dockerfile: Dockerfile
environment:
- NODE_ENV=development
volumes:
- '.:/app'
- '/app/node_modules'
ports:
- 4000:4000
restart: always
Dockerfile
# Use the official image as a parent image.
FROM node:current-slim
# Set the working directory.
WORKDIR /app
# Setting environment path.
ENV PATH=/app/node_modules/.bin:$PATH
# Copy the file from your host to your current location.
COPY package.json .
# Run the command inside your image filesystem.
RUN npm init --yes
RUN npm install --save cors apollo-server-express express graphql reflect-metadata type-graphql apollo-datasource-rest soap jsonwebtoken --yes
RUN npm install nodemon -g --yes
# Add metadata to the image to describe which port the container is listening on at runtime.
EXPOSE 4000
# Copy the rest of your app's source code from your host to your image filesystem.
COPY . .
CMD [ "nodemon", "index.js" ]
Dependency Error
$ docker-compose up --build
Building apollo
Step 1/10 : FROM node:current-slim
---> f3f62dfcc735
Step 2/10 : WORKDIR /app
---> Using cache
---> 33088e65c748
Step 3/10 : ENV PATH=/app/node_modules/.bin:$PATH
---> Using cache
---> c7f742267b26
Step 4/10 : COPY package.json .
---> Using cache
---> 76285ea4a8ca
Step 5/10 : RUN npm init --yes
---> Using cache
---> 29a3d715136b
Step 6/10 : RUN npm install --save cors apollo-server-express express graphql reflect-metadata type-graphql apollo-datasource-rest soap jsonwebtoken --yes
---> Running in 1e4472bcd901
npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR!
npm ERR! While resolving: apollo-express-server#1.0.0
npm ERR! Found: graphql#15.4.0
npm ERR! node_modules/graphql
npm ERR! graphql#"^15.3.0" from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer graphql#"^0.12.0 || ^0.13.0 || ^14.0.0" from graphql-middleware#4.0.2
npm ERR! node_modules/graphql-middleware
npm ERR! graphql-middleware#"^4.0.2" from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR!
npm ERR! See /root/.npm/eresolve-report.txt for a full report.
npm ERR! A complete log of this run can be found in:
npm ERR! /root/.npm/_logs/2020-11-05T16_19_42_605Z-debug.log
ERROR: Service 'apollo' failed to build : The command '/bin/sh -c npm install --save cors apollo-server-express express graphql reflect-metadata type-graphql apollo-datasource-rest soap jsonwebtoken --yes' returned a non-zero code: 1
There is not need to downgrade to npm 6.
Indeed npm 7 can still be used with option --legacy-peer-deps.
npm install --legacy-peer-deps
The problem here is certainly with NPM and the packages you are trying to install rather than anything to do with Docker.
Unfortunately, I am not able to reproduce the exact error that you are facing. That could be because:
something changed in the time between now and whenever this problem occurred;
there are some essential details that you are not showing us.
Either way, there's a general way in which such issues are solved, which should help. But first an explanation.
Dependencies, peer dependencies and conflicts
NPM's package (dependency) management mechanism allows packages (dependencies) to have:
(direct) dependencies - installed automatically with the package;
peer dependencies - have to be manually installed by the consumer of the package.
However, NPM does not allow multiple versions of the same package to coexist.
Also, as you may know, packages use standard semantic versioning, which means that a major version change indicates a breaking change.
Due to these two reasons, clashes occur if one package requires dependency A to be v1, while another wants the same dependency A to be v2.
NPM v7
NPM v7 was recently released and this is the version that current (as of November 2020) node:current images use.
Probably the biggest changes brought about by NPM7 relate to peer dependencies - NPM should now be able to install them automatically, if possible. Read more here.
As described in the document, in cases where it's not possible to solve the conflicts, NPM should now throw errors rather than warnings, which is what you are seeing.
I, on the other hand, only managed to get warnings and no errors using your setup and NPM v7.0.8, and I don't know why. The problems reported were essentially the same, however, so the resolution ought to be very similar.
How to solve conflicts
The only solution that I'm aware of is manual conflict resolution - the developer needs to adjust their dependencies to play along.
In your specific case the problem seems to be with the graphql package. The latest graphql package is v15, which is also a peer dependency of the latest type-graphql package (v1).
However, apollo-server-express has a few dependencies, which apparently only support graphql up to and including v14.
While you wait for apollo-server-express to fully support v15, you may opt for graphql v14 altogether by downgrading the only package that requires v15. So if you change your npm install to this:
npm install --save cors apollo-server-express express graphql#14 reflect-metadata type-graphql#0 apollo-datasource-rest soap jsonwebtoken
it ought to work... Notice that we are explicitly installing graphql#14 and type-graphql#0 (yes, version zero).
Alternative solution
Going to give you some bad advice too. In some cases a missing peer dependency may not be a problem, particularly if you never use the related functionality. In your case, it may be even less of a problem because you do have the dependency, just not the required version. It's entirely possible that a wrong version would do just fine. If you feel lucky (or if you're sure of you're doing) and you really wish to proceed with graphql v15, you could either:
suppress any NPM output to silence the errors;
downgrade to NPM v6, which works quite differently (although it will still warn you of peer dependency problems).
Proceed with caution!
I have a similar error, in my case just need to manually install all dependencies
npm install --save express
npm install --save express-graphql
npm install --save graphql
npm install --save mongoose
npm install package_name --legacy-peer-deps
Or
npm install package_name --force
Will fix the issue.
I had the same issue while trying to build a reactJS application in which i had used CoreUI and other JS libraries. Some of this dependacies i noted they use legacy dependacies in them and seemed like in their package.json file they have explicitly specified a version to be used. After trying all this solutions above, docker (docker build .) still could not build my image.
i changed my base image from node:16-alpine3.11 to node:12-alpine3.11 and everything worked perfectly.
Using this base image i was able to avoid using
npm install --save --legacy-peer-deps which failed to work on my case
My recommendations to anyone who might experience this issues is to just try various node docker images.
I've a frustrating issue when "npm install" is executed inside a Jenkins Groovy pipeline using the NodeJS plugin, the process hangs with the following error -
npm install --ddd ng-cli
npm info it worked if it ends with ok
npm verb cli [ '/var/jenkins_home/tools/jenkins.plugins.nodejs.tools.NodeJSInstallation/nodejs893-v2/bin/node',
npm verb cli '/var/jenkins_home/tools/jenkins.plugins.nodejs.tools.NodeJSInstallation/nodejs893-v2/bin/npm',
npm verb cli 'install',
npm verb cli '--ddd',
npm verb cli 'ng-cli' ]
npm info using npm#5.5.1
npm info using node#v8.9.3
npm verb npm-session e522ad0a36f1c038
npm sill install loadCurrentTree
npm sill install readLocalPackageData
npm http fetch GET 503 https://registry.npmjs.org/ng-cli 70252ms attempt #3
npm sill fetchPackageMetaData error for ng-cli#latest 503 Service Unavailable: ng-cli#latest
npm verb stack Error: 503 Service Unavailable: ng-cli#latest
When the command is executed directly on the EC2, the package installs without issue as the Jenkins user.
Also when the command is executed inside the Jenkins Docker, the package installs without issue as the Jenkins user using the same Node installation.
The Docker instance is not limited by CPU or RAM.
The setup is Jenkins v2.138.1 running inside a Docker container, which in turn is hosted on an EC2 v2018.03. Jenkins home is mounted as an EFS volume. The JVM is running on Java v1.8.0_181. NPM is v5.1.1.
Any pointers would be much appreciated.
Reply to first suggestion
Yes there is direct internet connectivity, without any proxy. If a single package is installed such as
npm install ng-cli
The npm install works without issue.
The issue consisted of two parts -
First off - the EFS mount point directory (/var/jenkins_home) required permissions of 777, it doesn't need to be a recursive permission.
The new EFS disk had content migrated from the old Jenkins EFS and this was also contributing to this issue. The fix was to not transfer any content from the old EFS to the new EFS via the backup.tar.gz feature. The new Jenkins is working as expected with npm install.
Dockerfile pulled from - https://hub.docker.com/r/jenkins/jenkins/