OpenMRS Platform 2.6.0-beta (Ready for Testing)

Greetings Everyone,

We are moving away from the OpenMRS Platform 2.6.0-alpha release and have reached the beta phase of the release of Platform 2.6.0, having subsequently released core 2.6.0-beta.

The OpenMRS Platform 2.6.x build is now passing and ready for End to End testing

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.

Find the prelease notes/documentation for OpenMRS Platform 2.6.0-beta at https://wiki.openmrs.org/display/RES/Platform+2.6.0-beta+Release+Notes

Platform 2.6.0-beta can be found in the following places;-

NOTE:

Looking forward to your contributions towards the successful release of platform 2.6.0. Thanks in Advance!

/cc: @abertnamanya @dkayiwa @burke @grace @tendomart @ibacher @jayasanka @piumal1999 @dennis @Mekom @PIH @jwnasambu @ugandaemr @kdaud @AMPATH @ruhanga @christine @devnull @dev1 @dev2 @dev3 @dev4 @dev5

4 Likes

Thank you so much @mherman22 :pray:

@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?

Thanks @mherman22 will dedicate sometime

1 Like

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.

Stack trace here

A screenshot of the error in question:

1 Like

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.

@raff, @ibacher, @dkayiwa would you know?

We just changed the release process not to use the maven-release-plugin. That’s all that’s happening there.

The other thing is probably the same problem described here.

@raff Do the Corretto-based images need something do to generate default locales?

1 Like

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.

I don’t know. I haven’t seen this issue locally. @ruhanga what’s the way to reproduce? Is this when running with the new corretto-based images or plain war? Does running ‘sudo locale-gen’ as suggested at "Theme 'green': No message found under code 'favicon' for locale 'en_GB'." - #3 by bawanthathilan help?

1 Like

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.

Update:

We can test this beta release using the qa-refapp server aswell since it has been updated to run against platform 2.6.0-beta.

FYI, we can utilize the automated tests that were written to test this prerelease. To do this locally, follow the steps below broken down from https://wiki.openmrs.org/pages/viewpage.action?pageId=235277297

  • clone the repository → https://github.com/openmrs/openmrs-contrib-qaframework.
  • cd into the repository using → cd openmrs-contrib-qaframework
  • Navigate to the qaframework-bdd-tests module using → cd qaframework-bdd-tests.
  • trigger npm run in the terminal in order to see all the workflows that have been created
  • Trigger any test workflow by running the command: → npm run workflowName, i.e npm run refapp2ClinicalVisit

Results: lets capture the results here → https://docs.google.com/spreadsheets/d/1c9A7RynOwyH-2DJHJ-y3mJvHxc7E3laTEq5_BC3JvGM/edit#gid=0

/cc: @jwnasambu @jayasanka @piumal1999 @Mekom @PIH @jwnasambu @ugandaemr @kdaud @AMPATH @ruhanga @christine @devnull @dev1 @dev2 @dev3 @dev4 @dev5

3 Likes

Reminder to @ibacher that you talked of pointing the dev3 server to openmrs 2.6.0-beta during yesterday’s platform call.

@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.

Thanks @kdaud , this saves a lot of effort/resources that would go into local setup.

Lesson taken :slight_smile:

@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.

Noted with thanks @kdaud

landed on security through obscurity :slight_smile: when i tried to find out why

@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?

1 Like

I have updated it.

The plan is throwing a different error. Using GITHUB_TOKEN may require granting some permission in order to trigger workflow(s) in another repo.

Alternatively we can return to using personal access token(PAT) and then update it.

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).

/cc: @kdaud