I don’t think we need to import any data. The idea is to run the tests against an empty database and let the tests insert the initial data. It’s already done for the in-memory DB, it just needs to be tweaked to connect to a “normal” database.
Is there anyway I can test that?
Because after running docker container (and waiting a little bit), we’d have an empty database.
So I’d like to set up a build which starts database, import data and run the tests - but I have no idea how it’s done for OpenMRS. If you could give me hints and tips, I guess I could find my way.
Hi Cintia,
Currently the only way to not use the in-memory database H2 is to manually change the code (specifically make BaseContextSensitiveTest.useInMemoryDatabase to return false). This is not very practical. My proposal is to make it possible to change this behaviour externally by means of environment variables. The process will be as follows:
Check existence of openmrs.test.useInMemoryDatabase If not exists or is true Then connect to H2 database Else read environment variables - openmrs.test.connectionstring - openmrs.test.user - openmrs.test.pwd connect to external database End
Delete all tables (*) Insert initial data
(*) deactivating the FKs uses non standard SQL commands, maybe I’ll need to add the db dialect also to the env vars
I agree, we need to make opting out of using the in-memory DB configurable externally
@cintiadr, have you gotten what you need to move this forward? Or could you use help (information and/or some peoples’ time)?
@lluismf, @wyclif – do we have a ticket to make our tests use a database specified in an environment variable (i.e., allow environment variable(s) to optionally specify a db connection other than H2)?
@michael, @ryan – what would it take to get Bamboo updated to latest (5.9)? Atlassian has been adding some nice docker features in the past couple versions that would help @cintiadr move forward with mariadb-based builds.
It should just be a matter of scheduling some maintenance time for bamboo. Either @cintiadr or I will want to try out the upgrade in staging just to make sure everything goes smoothly.
1 Like
I have created this issue to add support for setting test database credentials externally:
The docker tasks in Bamboo is a nice wrapper for the docker command, but it doesn’t add any new functionality to it.
(Well, it can wait for a URL to be available, but I don’t think there’s anything else).
Of course, it’s nice, but it doesn’t change how to handle the container.
We set a goal of supporting MariaDB by this September’s OpenMRS 2.3 release. “Supporting MariaDB” means our builds fail when our code doesn’t run on MariaDB as well as MySQL.
Do you think this goal is attainable with the time & effort you all have between now and September?
If not,
- Do you think we need to seek additional volunteers to meet that goal?
- Are there specific tasks we should solicit help with to reach our goal?
- Are there specific blockers we could help eliminate?
- Other thoughts/concerns?
I appreciate the contributions you’ve already made and want to help build on those efforts to get the community to sustainable builds against MariaDB.
Cheers,
-Burke 
1 Like
I use mariadb on my linux system, and I’ve been using it for my GSoC project too. So I guess more hands always do lighter work. The more volunteers we can have for these tests the better an appraisal we can get and easily fix most of the issues associated. I’ve not started running it on the most current release. But I’ll try to test it on Fedora and see how it goes. But I guess with more volunteers this can easily be done by September to support to next release for OpenMRS.
1 Like
Next week I’m on vacation but in august I’m free, I’ll try to help with the test class.
1 Like
September looks distant enough 
But I need someone willing to setup the build, setup a instance using jetty:run or similar on the agent with the mariadb docker container. I still have no idea how to do that, how to start OpenMRS and configure it to use an specific database.
Is there anyway to configure it by a file? Or how to populate the data.
How about using openmrs-sdk for that?
You basically need to call openmrs-sdk:setup to provide specific database details and then openmrs-sdk:run to run it. All commands can be run in batch mode by providing all required parameters.
I’m sure @dmytro_trifonov will be happy to further assist you with that.
1 Like
That looks like exactly what I needed.
I will try it later and see if I can get anything working, cheers
I believe I got something working.
https://ci.openmrs.org/browse/RELEASE-MDT-15/log
The a sdk:setup works pretty well! It connected to the database on the docker container, and everything else.
But I cannot use sdk:run on the build, right? I see it’s using jetty:run-war, I suppose we’d need something different.
2 Likes
@cintiadr, can’t you simply tell docker to startup OpenMRS using mvn openmrs-sdk:run -DserverId=someServerId? In other words you could have another container running OpenMRS. You would have to execute openmrs-sdk:setup in that container as well before running.
If you used defaults for version in the setup command, the sdk will startup OpenMRS 2.2. In the final version of OpenMRS SDK (to be released on Wednesday) we will be able to run 2.3-SNAPSHOT (the latest development version).
I certainly can run it on docker