trion-development / docker-ng-cli-e2e

Angular end2end tests inside docker
MIT License
24 stars 11 forks source link

Problem with 7.2.3 #8

Closed DeyV closed 5 years ago

DeyV commented 5 years ago

image trion/ng-cli-e2e:7.2.3

command: ng test --watch false

Error:

ERROR in ./src/styles.scss (./node_modules/@angular-devkit/build-angular/src/angular-cli-files/plugins/raw-css-loader.js!./node_modules/postcss-loader/src??embedded!./node_modules/sass-loader/lib/loader.js??ref--14-3!./src/styles.scss) Module build failed (from ./node_modules/sass-loader/lib/loader.js): Error: Node Sass does not yet support your current environment: Linux 64-bit with Unsupported runtime (67) For more information on which environments are supported please see: https://github.com/sass/node-sass/releases/tag/v4.9.3

On trion/ng-cli-e2e:7.2.2 we don't have any problems with sass

everflux commented 5 years ago

Can you provide a sample project? Have you tried to remove the node_modules folder and package lock/ci files and do an 'npm install'?

DeyV commented 5 years ago

error.txt project.zip

Empty project and error

everflux commented 5 years ago

The empty project was created using 7.2.3 of the cli? With or without the docker image?

codecoster commented 5 years ago

When I try to run your project, I get the error "can only install packages when your package.json and package-lock.json or npm-shrinkwrap.json are in sync. Please update your lock file with npm install before continuing" (when using npm ci). After removing the package-lock.json and reinstalling everything it seems to work (but e2e test fail, but because of a missing dependency ("error TS2688: Cannot find type definition file for 'jasminewd2'.")

dorotazielinska93 commented 5 years ago

The empty project was created using 7.2.3 of the cli? With or without the docker image?

The project was created using 7.1.4 of the cli, but when we use image trion/ng-cli-e2e:7.2.2 it works just fine.

dorotazielinska93 commented 5 years ago

we have currently many applcations which are using the latest version of image trion/ng-cli-e2e and it was fine till last week. We even tried to run pipeline without any changes in projects and it failed on tests with this error. Changing image trion/ng-cli-e2e:7.2.2 solve the problem, is there any problem with image trion/ng-cli-e2e:7.2.3?

everflux commented 5 years ago

Are you using :latest or :7.2.3? Latest is currently using a reduced base image based on Debian-slim to minimize the size without switching to alpine. Do you experience the Problem when removing the package lock file and running npm install afterwards ?

DeyV commented 5 years ago

We have problem with latest. I have not noticed that the latest and 7.2.3 is not the same.

dorotazielinska93 commented 5 years ago

with 7.2.3 everything it works fine, thanks :)

everflux commented 5 years ago

Ok I will check what might break due to the changed base image in your case.

DeyV commented 5 years ago

for the future = it's a good practice to test new solutions on the dev tag, not necessarily on the latest ;)

btw. thx for your work - We really appreciate the ability to use yours images

everflux commented 5 years ago

The problem is that nobody tests -dev and without feedback it is not helping. We testet the slim base image with some projects and fixed problems (like python dependency and gcc for sass build /node-gyp) so pushing it as latest was the only sensible way to move forward.

everflux commented 5 years ago

I can not reproduce the problem. Did you try removing the package lock file and running a fresh npm install before running the ng test?

codecoster commented 5 years ago

I can not reproduce the problem. Did you try removing the package lock file and running a fresh npm install before running the ng test?

I might add that the npm install should also be done from within the docker container

DeyV commented 5 years ago

We use this image in Gitlab CI pipline, so this approach is problematic for as - because we need cache. So now in different step we create cache with npm packages, and later we use it in test and build steps.

everflux commented 5 years ago

I would recommend to start each pipeline run with a clean state and use the cache only for the subsequent steps during a single pipeline run. You might want to use the commit hash as cache discriminator to achieve that.

DeyV commented 5 years ago

we do exactly like that. Part of our gitlab ci file:

init:
  image: trion/ng-cli:latest
  stage: init
  script:
    - yarn
  cache:
    paths:
      - node_modules/ 

test:
  image: trion/ng-cli-e2e:latest
  stage: test
  script:
    - ng test --watch false
    - ng e2e
  cache:
    paths:
      - node_modules/ 

build:
  image: trion/ng-cli:latest
  stage: build
  script:
    - ng build
  cache:
    paths:
      - node_modules/

And something must be wrong, when we know, that ng-cli-e2e is build on ng-cli, is exactly in the same version, in the same yarn, npm locks, and still, after last change in this images, we have this strange error.

BTW.

I checked Your changes in this image. And i'm afraid, that this change, despite reducing the size of the image, it will not save bandwidth. Why?

  1. ng is updated much more often than node base image.
  2. in latest every update in ng-cli will download git, python and build-essential in new layer, which earlier was in node base.
  3. node:stretch == node:latest - is most popular version of this image - so on many servers is already downloaded.

So it seems to me that this is a micro optimization that will not bring much benefit, but make new problems.

codecoster commented 5 years ago

Even with yarn, I can not reproduce your error. Could you please provide a project to recreate the error conditon and the exact steps to recreating the issue? I even checked the project provided above, but it has no yarn.lock file, could you also provide your lockfile?

everflux commented 5 years ago

If you experience the problem again, please reopen with exact steps and project to reproduce the issue.