Platform test coverage so we don't break Initializer workflows?

Hi team @dkayiwa @jnsereko @kdaud @ibacher @burke @mksrom,

@binduak shared an issue today in the #initializer slack channel, which made me realize: What automated tests do we have set up to prevent or alert us when changes to the platform would break Iniz workflows? Given we are increasingly recommending Iniz to many many distros, this seems like coverage we need.

Specific message from @binduak was:

Hi @Dimitri R @Ian Bacher We are getting below error with initializer 2.4.0-SNAPSHOT on OpenMRS 2.4.2 env. The other module csv imports(concepts, conceptset…etc) are working fine on the env but liquibase module upload with initializer is giving below error. But the same functionality worked fine on OpenMRS 2.1.7 env.

ERROR - BaseFileLoader.lambda$loadUnsafe$3(89) |2022-07-20T15:36:38,585| There was an error while updating the database to the latest. file: /opt/openmrs/configuration/liquibase/liquibase.xml. Error: /opt/openmrs/configuration/liquibase/liquibase.xml does not exist

Even if this specific issue does not end up related to a breaking change in our platform, my question remains: What test coverage do we have in place?

I guess these tests should probably live in Iniz, but we should have them represented in our relevant dashboards (eg Bamboo build-time alerts and the OMRS qaframework dashboard).

CC @alaboso @amugume who might find this interesting.


Initializer Validator?

That was supposed to be the answer to validating configs before they fail you on a runtime env.

See also the unfinished (by me, when I used to do some useful work):

  • SDK-269: openmrs-contrib-packager-maven-plugin to validate OpenMRS configs.
1 Like

Every module is in the same boat, and the solution is typically with unit tests for each feature and maven profiles that build and test against different platform versions. The reporting module does this as you can see here: Reporting Module - Reporting Module 894: Build result summary - OpenMRS Bamboo. Also as you can see, it can be difficult to keep this up-to-date, and requires active maintenance - the versions tested with reporting appear to be 1.9 - 2.2.

1 Like

:grimacing: @dkayiwa how do you think we could manage this? Eg do we have a pre-platform-release checklist? Should we add test support for the reporting module as a must-have before platform updates? That’s like 2 years out of date with the platform which feels wrong.

Looks right for critical modules like iniz.

1 Like

Hi @dkayiwa @ibacher @mksd @grace,

Adding to this thread,

We have loaded openmrs-referenceapplication using docker-compose from below link

After that, with the modules which are already there,

  • We added initializer-2.4.0-SNAPSHOT.omod from initializer module master branch and
  • Added liquibase.xml file on .OpenMRS/configuration/liquibase folder path, so this file would get picked up with initializer

Still we are getting below error

ERROR - BaseFileLoader.lambda$loadUnsafe$3(89) |2022-08-17T08:59:56,224| There was an error while updating the database to the latest. file: /usr/local/tomcat/.OpenMRS/configuration/liquibase/liquibase.xml. Error: /usr/local/tomcat/.OpenMRS/configuration/liquibase/liquibase.xml does not exist

Can you please provide technical help to fix the issue so that we will raise a PR?

Thank you

1 Like

Thanks so much Rohit for calling this out. I’ve also alerted the #openmrs-initializer slack channel. @mseaton or @alaboso or @dkayiwa or @solemabrothers may also be able to share some guidance?

@raff sorry if this is a silly question but: is there anything in your current dockerization work that might unblock Rohit’s finding, that Iniz is not working as expected with the default OMRS container running 2.4.2?

@rohit.yawalkar what process did you follow? How did you add the liquibase.xml file into the docker container? What are the contents of your liquibase.xml file?


I have just been able to reproduce this on platform 2.4.x by simply putting an empty liquibase.xml file in the configuration/liquibase folder of the application data directory. Since i was not able to reproduce it from platform 2.5.x and above, i looked at the changelog and it looks like the fix was done by @mseaton here [TRUNK-6077] OpenMRS 2.5+ unable to execute liquibase files outside of classpath - OpenMRS Issues

So @rohit.yawalkar you can either back port those changes to the 2.4.x branch or simply use platform 2.5.5


Hi @mseaton, From below link we loader openmrs container And by doing docker exec, added .Openmrs/configuration/liquibase/liquibase.xml file with some migration. Then after adding initializer module and restart, we are getting the error

Hi @dkayiwa,

Thanks for looking into this, as you have added, we are working on spike to understand efforts needed for, either to go with backporting changes to 2.4.2 or shifting to 2.5.5

Thank you

1 Like