I am therefore calling upon all volunteers, implementations, distributions, squads and all other interested parties to test out this prelease version of OpenMRS Platform 2.6.0.
@Platform_Team (Ian?) / @ruhanga - could you list here already the points, top of your head, that would prevent upgrading Ref App 3.x to Core 2.6, if any?
May not be quite a stringent blocker for an upgrade of the Ref App but worth resolving. We’ve noticed this
Error on page /openmrs/errorhandler.jsp javax.servlet.jsp.JspTagException: Theme 'green': No message found under code 'stylesheet' for locale 'en_US'
randomly happening with the Ref App in Ozone as of Core 2.5.9 (happens with Core 2.6.0-beta as well), which requires an additional restart of the OpenMRS webapp for the second time, at least the very first time a Ref App instance is spun up. This would be worth a test from any of the release managers or community members to confirm.
Something also seems odd with the Core branch 2.5.x on github and the way 2.5.9 was released - whether it was actually released to OpenMRS marven artifactory in the end? Might be somewhat connected to this conversation.
PS AFAIK there’s nothing that would prevent us adopting 2.6.0 into the RefApp. However, some work is needed with the CSRF stuff, that’s one of the main additions. Right now, it just doesn’t affect the REST and FHIR endpoints, but that’s not a good long-term strategy.
Thanks for the suggested fix @raff, @ibacher. I’m aware that we mount an openmrs.war binary to an OpenMRS docker image (possibly not the new corretto-based images ), @achachiez to confirm and possibly test with the suggested fix. Otherwise to reproduce the above reported error quickly, you’d want to run an Ozone instance found @ ozone-his/ozone-docker. Its OpenMRS related artifacts are mostly published by OpenMRS except for one or two modules which don’t seem to be related to the error.
Well, if you’re not using our Docker images, it is a bit harder guess. IIRC, the default locale for the system running OMRS should be either en or en_GB, not en_US. Ultimately, though, that error is caused by a Spring tag that’s looking for a translation in the system-level default locale. I suspect that you’d have the same error with 2.5.0 plugged into the same image your using.
@mherman22 we can take advantage of github actions since it’s configured to run the tests in a docker environment that consumes a local host server which uses an updated image of qa-refapp.
So one can run these automated tests directly via github actions by triggering a manual run and a reliable test-report is provided after the build plan. This requires a privilege if one is to run them directly on our upstream repo however, those without privilege can run them on their updated forks.
@mherman22 It would be a good idea for the url to the test report point at the final plan remark(either Build success or Build failure). Though the cucumber reports look prettier good but only lasts for 24 hours and then get destroyed.
@mherman22 FYI we have automated tests for platform UI that covers installation and upgrade so we can take advantage of them and add them on the Google sheet.
@dkayiwa our automated tests are no longer running for any push done on core and the log shows the culprit to be the credentials. It’s probably our token got expired, could you help to update it because my hands can not reach those settings on core?
As i try to finalise this testing phase of beta, i have got the patient visit note test failing and the all firefox tests is also failing.
The patient visit note seems to be failing with this error → org.openqa.selenium.TimeoutException: Expected condition failed: waiting for visibility of element located by By.xpath: //ul[1]/li/span/div/strong (tried for 60 second(s) with 500 milliseconds interval).
