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?
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?
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
cd openmrs-contrib-qaframework
cd qaframework-bdd-tests.npm run in the terminal in order to see all the workflows that have been creatednpm 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
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.
@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?
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
What happens when you re-run the test?
I have reported this after my second re-run
Are you able to reproduce the issue locally?
when i change headless to true, it passes but headless to false it fails with mherman22@kuntakinte:~/Documents/git-repositories/git-openmrs/openmrsQA/openmrs- - Pastebin.com
Does it pass with firefox driver when headless=false ?
