Nevermind… it’s just DevTools that tries to load the non-existing map. It should not affect the app… Let’s dig further…
@raff i do not think it has anything to do with the docker set up. For i get exactly the same issues even when i do not use docker. That is when i manually set up a local server using this: openmrs-distro-referenceapplication/spa-build-config.json at 3.x · openmrs/openmrs-distro-referenceapplication · GitHub
That’s correct. I think there’s some mismatched dependency versions of esm components. I’m following up with @ibacher on Help to unblock issue with Reporting & Reporting REST modules in O3? - #26 by raff to understand a bit more on how things are bundled together.
is there any way i can override the import file and serve my own patient chart just like import-map-overrides as specified in the o3 openmrs documentation
i need to make clinical visit test working and i would wish to try it out on my local running o3 instance using docker.
at the same time, i would wish to do some performance testing on patient-chart in the current docker instance
- O3-1405: Fix clinical visit test
- O3-1407: Fix vitals and triage test
- O3 1404: Fix user settings test
At the same time, i don’t understand the CI that results into updating the nightly docker instance for 3.x. Knowing this, i guess would give me a better picture of what is happening.
Also being able to override the version of patient-chart running. on the docker instance, i guess, might also help me verify that it is actually Patient-chart failing not any other esm app
Locally, you can build the Docker images and change the versions in this file to whatever you want.
It’s absolutely patient-chart that’s failing. Everything on the patient chart is rendered in this React “page”. When we look at the screen, e.g., as shown below:
You’ll see the
SideMenu component is loaded (the left menu), but that the spinner is where the
PatientChart component should be. Everything in the center of the patient chart screen is rendered into one of 3 extension slots. But, those extension slots are not rendered and, if you look in the main content (CSS selector
#single-spa-application:@openmrs/esm-patient-chart-app-page-0 > div > main, you’ll see the only thing there is the loader.
hello @dkigen. I failed to solve this issue
I was able to see all this and it is the loader rendered and the state of
isLoading doesn’t change.
Alright, progress! Basically building the images with the updated version of the frontend seems to work.
For now, I can’t get the frontend to build on ARM architecture, so, unfortunately, the nightly version of the frontend image is only available in AMD64. The backend and the gateway both have ARM64 images available, though.
Thanks, @ibacher Now we can see test workflows are passing in GitHub actions. (But some test are failing)
I couldn’t figure out why the dev step was failing on arm64, but I figured we didn’t need to have this step in arm64 as the result is the same as in amd64.
hey @ibacher @dkayiwa @raff @pasindur2 Basing on the latest pull, docker instance for 03 ain’t working. I get a blank screen. Its like the getway and the backend images don’t start successfully. 502 bad getway - Pastebin.com
At the same time, i think the functionality of registering a patient Might be broken. However i am not so sure because i cant even login to check if its working well.
What’s the output from
docker-compose ps and
docker-compose logs backend?
docker-compose -f docker/docker-compose-refqa-3x.yml ps NAME COMMAND SERVICE STATUS PORTS docker-backend-1 "dumb-init /usr/loca…" backend running (unhealthy) 0.0.0.0:8080->8080/tcp docker-db-1 "docker-entrypoint.s…" db exited (1) docker-frontend-1 "/docker-entrypoint.…" frontend running (healthy) 80/tcp docker-gateway-1 "/docker-entrypoint.…" gateway running 0.0.0.0:80->80/tcp
Could you try running
docker-compose down -v and then restarting the docker-compose process?
i am still seeing a blank screen at
However, the backend at
http://localhost:8080/openmrs/index.htm is working fine (i was able to login)
Well, that’s some kind of progress maybe… Are you still seeing 502 errors in the JS console on your browser?