We can try to test if an ARM-specific build will fix things. Unfortunately, I don’t have access to an M1, but if you checkout the 3.x branch of this project (git clone -b 3.0.0-alpha.4 --single-branch git@github.com:openmrs/openmrs-distro-referenceapplication.git) and then build it mvn clean install, you can then run the docker-compose in the run/docker subfile of that folder which should now be an ARM build of everything… assuming ARM versions of the base images we rely on exist.
If that works, we can look into how we get ARM versions of our images built automatically for you…
Hi @ibacher, thank you for the response. I tried building it by following your instructions, but the build fails and throws an error saying that the package.json file is missing. There’s a package-lock.json file inside the openmrs-distro-referenceapplication/package/ directory. But the package.json file is missing.
The esm versions in the actual frontend deployment are different than the versions shown in the error. I’ll try rebuilding it and let you know if the problem doesn’t get fixed
Update 2022-03-04T18:30:00Z: It works correctly with the latest version
@ibacher did you make any progress on multi-arch builds? I could definitely build it locally and publish to dockerhub to unblock people. On CI we will need to upgrade the linux kernel on Bamboo agents to support multi-arch builds. We were awaiting that for OCL as well.
@cintiadr are there any plans to upgrade kernels in not so distant future? If not, would it be okay for me to look into upgrading bamboo agents only or does it need to happen for all our instances for consistency?
The good(ish) news on this front is that Jetstream is being retired in favour of Jetstream2; from the chat on the #infra channel on Slack, I think part of the migration will involve moving to at least Ubuntu 20.04, i.e., we’re going to have to migrate the infrastructure anyway…
It might be helpful if you could push the images out there.
Generally what happens here is that an earlier build step failed. If you look up in the log, you should see something shortly after Maven logs a message about running a long command that includes npm exec -- openmrs@... build . When this build fails, the index.html file doesn’t get created. Under some conditions (and I’m not really sure what those are), the webpack run triggered by openmrs build fails, but the openmrs executable (for some reason) doesn’t catch that, so the rest of the build proceeds as if it had succeeded.
Hopefully a git pull to get the latest version of the 3.x branch helps, but if you could post the full build log that would also be helpful.
Since this is Docker, if you don’t mind losing any data you might have locally, docker compose down -v will destroy the associated volumes which should handle both deleting the lucene directory (as @dkayiwa suggested) and undoing whatever caused some file to be created by MariaDB 10.7 (though I don’t think there’s a good reason we couldn’t support 10.7).
