npm run e2e doesn't pass for reactive-ms JDL

[mraible]

Overview of the issue

To prepare for my Reactive Java Microservices with JHipster talk at Spring I/O on May 26, I decided to try my demo script with the latest release.

I made it to the part where you run npm run e2e. At that point, it fails on two tests:

• When testing /docs
• When trying to add a new post

For Swagger, nothing renders and there's a stack trace in the console.

For adding a new post, it seems that the Save button is never enabled.

Motivation for or Use Case

Everything worked when I wrote the post in January 2021 and when I recorded a screencast of it in May 2021.

Reproduce the error

Run jhipster jdl reactive-ms, start all the Docker containers and apps, run npm run e2e from the gateway's directory.

JHipster Version(s)

7.8.1

Browsers and Operating System

• macOS Monterey, version 12.3.1, M1 Max
• Chrome 100.0.4896.127
• Node.js 16

[mshima]

I will try to reproduce.

[mshima]

The swagger problem is because the endpoint are not ready yet.

[mraible]

When I tried it in Chrome, it didn't work. Do you mean it's not implemented or it's not ready to take requests?

…

On Tue, May 3, 2022 at 19:42 Marcelo Shima ***@***.***> wrote: The swagger problem is because the endpoint are not ready yet. — Reply to this email directly, view it on GitHub <#18570 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAELZEJEREZALNKEY3LPPTVIHIXNANCNFSM5U7WBCGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[mshima]

Not ready to take requests.
I couldn't reproduce.

[mshima]

Just tried using chrome, it works.
Maybe it's because it's taking too long to respond, the timeout is 5s.
Are you using amd64 image on m1?

[mraible]

Yes, I am using M1 and Cypress is noticeably slower. I'd expect the app to work though, even if the Cypress test fails.

[mshima]

I tried to make swagger loaded urls dynamic but failed.
The urls needs to be loaded and parsed before creating the swagger ui.
We can increase the timeout, but the user experience will be worse IMO.

I suggest to create arm64 images.

[mraible]

I created Docker images to test things. When I tried starting everything with docker-compose up, it took a long time to start all containers. The gateway app was unreachable.

I stopped all containers and bumped up the available resources.

Then, I enabled Docker Compose V2.

Then, I tried docker compose up. This seemed to be much faster. Now when I run npm run e2e, all tests pass except for creating a post.

I can try on Intel to make sure it's not an M1 issue.

[mshima]

@mraible the linked PR should fix the post error.
I could not reproduce the swagger problem, but it should happen if the gateway takes more than 5s to respond.
The PR adds java:docker:arm64 script to build arm64 docker image.

[mraible]

The linked PR does fix the post error. The /docs test still fails with Cypress. I tried loading http://localhost:8080/admin/docs in Chrome and it takes 11 seconds. If I build Docker containers for all the apps and run them with docker compose up, the gateway isn't reachable, even though it looks like it's up in the logs.

Docker seems to indicate that amd64 images might be slow.

Time to try Intel!

[mraible]

I didn't realize I needed to run npm run java:docker:arm64 to build M1-compatible images. Trying that now...

[mraible]

After creating new images with the above command, I tried docker compose up and npm run e2e. Still doesn't work.

[mraible]

On Intel, starting the apps with ./gradlew and running npm run e2e works just fine. In fact, the Swagger UI loads in a second or so. I'm not sure why it takes so long on the M1.

[mraible]

If I build Docker containers on Intel and start with Docker Compose, the product tests fail when running npm run e2e. If I restart the store app with Docker Desktop, it works.

[mshima]

After creating new images with the above command, I tried docker compose up and npm run e2e. Still doesn't work.

You need to delete the amd64 images to recreate as arm64.

[mshima]

All green on m1 here.
I have Experimental Features -> Use the new Virtualization framework enabled. It provides worst disk performance, but much better processing performance.

[mraible]

I can confirm that deleting the amd64 images and turning on Experimental Features solves the problem for me.

[mshima]

Generating both arm64 and amd64 works for docker repository like we do at jhipster-registry.
But doesn’t for local docker.

[mshima]

@DanielFran bounty claimed https://opencollective.com/generator-jhipster/expenses/90550.

[DanielFran]

@mshima approved