In terms of CI, we only use Travis to run “unit” tests rather than tests against a live MySQL database. What we would need is a new CI plan on the OpenMRS Bamboo server.
1 Like
Thanks @ibacher
So what we are planning is to create a CI plan for Bamboo server ( shifting from Travis ) and run the unit tests against a live PostgreSQL database in this case rather then using H2 database that is currently being used ?
Yes! This is because the propietary SQL extensions used the H2 database mainly used for running unit tests may fail. Though I would like you to differentiate between the CI plan for Bamboo server and Travis CI.
1 Like
Travis is easily integtated with github but for making use of Bamboo Server for continuous integration would involve :
-
running the tests at the Bamboo Server
-
generating the reports at Bamboo Server
-
Writing a script that continuously checks for status of build and informs github whether the build is pending or not.
-
Sending the build reports back to github as a final step.
This is the distinction I have found between Bamboo and Travis CI. Thanks @jwnasambu and @ibacher . Now I am able to understand what needs to be done. 
Am glad to hear that. I wish you the best in your application process.
1 Like
@aman The scope required here is actually a little less. ci.openmrs.org already is automatically triggered for each commit to the openmrs-core repo. What’s necessary is to add a step to the appropriate plan to run things against PostgreSQL. We already have tests on Bamboo and generate reports from Bamboo (these don’t pass back to GitHub, but I don’t know if that’s a requirement). We will still want to keep the Travis tests as well (the Bamboo tests trigger off of commits, not PRs).
1 Like
@ibacher I understood your point. Thanks again. 
1 Like
There are 25+ different modules (as mentioned here https://github.com/openmrs/openmrs-module-referenceapplication/blob/cf7f62e21c2cd6b7de03cf75cfc08bb8614291a7/pom.xml#L37-L65) that will be required to be tweaked to make them support PostgreSQL. Are there certain modules that will be required to be given higher priority as compare to others i.e. they must be resolved first in case we are not able to work upon all the modules in the given time frame or any seqeuence will be fine?
Some thoughts:
-
Not all of those modules will need to be tweaked, though many of them will, I suppose. Hopefully people have been relying on generic constructs (Hibernate, Liquibase).
-
I’d suggest the REST module is probably the highest priority, since it’s effectively part of the platform. Really if the platform and REST modules support PG, we can move other modules towards it slowly. I don’t have a sense of a good prioritization for the remaining modules.
-
The reporting modules likely require additional handling
1 Like
I guess beyond the platform, we need to make sure that distributions can run against Postgres.
The elephants in the room are:
- Ref App
- Bahmni
- The core set of modules that is needed to run the need MF-based “OpenMRS 3.0”.
My impression is that there’s a lot of work to get to a point where we can say that “OpenMRS” supports Postgres as it does MySQL. Hopefully I’m wrong.
And while we go through supporting Postgres, we should also support recent versions of MariaDB. It’s quite an issue and a concern that OpenMRS is stuck on MySQL 5.6…
4 Likes
Even supporting more recent versions of MySQL would be a step in the right direction…
Thank you everyone for helping me through making the proposal. I am planning to take the project “OpenMRS Should Run On PostgreSQL” for GSOC 2020. I have submitted the draft proposal and would be eagerly waiting for your reviews. Feel free to review my draft proposal at your own convenient time.
Special thank to @jwnasambu @ibacher @mksd for their insightful review on project tasks.
1 Like
I have updated my draft proposal according to a meaningful suggestion given by @ibacher . Feel free to review it at your own convenience. I will be waiting for your reviews.
As you wait for the review, kindly keep contributing to the tickets.
1 Like