Skip to content

README.md

Latest commit

 

History

History
141 lines (102 loc) · 6.62 KB

README.md

File metadata and controls

141 lines (102 loc) · 6.62 KB
Raw

PIH Sierra Leone EMR Distribution

This repository defines the OpenMRS distribution for PIH Sierra Leone. It packages together the PIH EMR parent distribution, Sierra Leone-specific content, and the PIH EMR frontend into a single deployable artifact. For more background on OpenMRS distributions, see the OpenMRS wiki.

Repository Structure

Directory Description
content/ Sierra Leone-specific OpenMRS content package (Initializer and O3 configuration files)
distro/ Distribution definition — resolves all component versions into openmrs-distro.properties

Components

Component Artifact
PIH EMR parent distro org.openmrs.distro:pihemr
PIH EMR shared content org.pih.openmrs:pihemr-content
Sierra Leone content org.pih.openmrs:pihsl-content
PIH EMR frontend org.pih.openmrs:openmrs-frontend-pihemr

Component versions are defined in distro/pom.xml and resolved into distro/openmrs-distro.properties at build time.

Supported Configuration Profiles

Site PIH Config
kgh sierraLeone,sierraLeone-kgh
wellbody sierraLeone,sierraLeone-wellbody
kgh-test sierraLeone,sierraLeone-kgh,sierraLeone-kgh-test
gladi sierraLeone,sierraLeone-wellbody,sierraLeone-wellbody-gladi

Using the OpenMRS SDK

Developers can use the OpenMRS SDK to set up, update, and run local OpenMRS instances. All normal OpenMRS SDK commands are supported.

One can also use the openmrs-sdk command supplied by the openmrs-contrib-distro-tools CLI if that is more convenient. Follow the installation instructions in that repo first if you wish to use this command. Consult the openmrs-contrib-distro-tools README for more information on each supported command and configuration option.

Setting up a new SDK server

Whenever one creates a new SDK server, there are several options one has to configure it. One must specify the distribution to install, the PIH Config to use, the Tomcat port, the Debug port, the Java version, and whether to connect to an existing database or to create a new one, and whether to do so in the default SDK Docker container, one's own Docker container, or in a native MySQL server. The openmrs-sdk documentation provides a full list of these options, which can be set via environment variables.

The least configuration required to get up and running is to specify the PIH Config only, which will use all other defaults including the database, which will use the built-in SDK Docker container.:

PIH_CONFIG=sierraLeone,sierraLeone-kgh \
openmrs-sdk create <server-id>

Many developers maintain their own MySQL Docker container into which they maintain their various SDK servers. For example, one might have an existing MySQL Docker container named mysq56 exposing port 3308, and with a root password of password. To use this container instead, simply add the appropriate additional environment variables as documented in the README:

PIH_CONFIG=sierraLeone,sierraLeone-kgh \
DB_CONTAINER=mysql56 \
DB_PORT=3308 \
DB_PASSWORD=password \
openmrs-sdk create <server-id>

Running an SDK server

This is just a thin wrapper around the native OpenMRS SDK maven command:

openmrs-sdk run <server-id>

Updating a server with the latest distribution (war, modules, owas, config, frontend)

Note

For those who are familiar with previously running ./pihemrDeploy.sh from openmrs-distro-pihemr, this is the equivalent of that, with the addition that this will also update the configuration and frontend.

openmrs-sdk update <server-id>

Updating only the configuration of a server

Unlike a full update, this only updates the configuration files and is intended to be faster, suitable for more rapid iteration of content changes for testing.

Note

For those who are familiar with previously running ./install.sh from openmrs-config-pihsl, this is the equivalent of that, with the exception that this will not automatically build in local changes to openmrs-config-pihemr. One will first need to run a mvn clean install in openmrs-config-pihemr to incorporate local changes from it.

openmrs-sdk update-config <server-id>

Using Docker

For each supported configuration profile, an example environment file is provided in the repo root to get started quickly. Because this file is found in the distribution repository, it is assumed that this is checked out on your machine, and that openmrs-docker commands are running from the root of the distribution repository — it sets DISTRO_SOURCE_DIR to this location. If you're using it as an example for running elsewhere, you may need to change or remove that.

To use the example environment file for kgh to get up and running with a new instance:

source kgh.env
openmrs-docker create kgh
openmrs-docker kgh initialize # Optional, but speeds up initial startup
openmrs-docker kgh start
openmrs-docker kgh wait  # Tails logs until OpenMRS is ready, then exits

Once created, day-to-day commands only need the instance name:

openmrs-docker kgh stop
openmrs-docker kgh logs
openmrs-docker kgh destroy

The same pattern applies to wellbody.env, kgh-test.env, and gladi.env — substitute the instance name accordingly.

CI and Publishing

CI is handled by GitHub Actions. On every push to master, the Build and deploy workflow:

  1. Builds and publishes the Maven artifact to Maven Central as org.pih.openmrs:pihsl-distro.
  2. Builds and pushes a multi-platform Docker image (amd64 + arm64) to Docker Hub at partnersinhealth/pihsl-emr, tagged with both latest and the Maven project version.
  3. Fires the existing Bamboo kgh-test and gladi deploy triggers, exactly as the legacy deploy.yml workflow did.

A separate Build seeded images workflow runs nightly and publishes a pre-initialized seed image to Docker Hub for the Sierra Leone country configuration (partnersinhealth/pihsl-emr-seed-sierraLeone).

A separate Update Versions workflow runs hourly and automatically commits any available snapshot dependency updates to master.