Quick CI approach for building & packaging Ebola module

I can think of these general approaches (some of which are hacky, but we’re going for quick-to-implement here):

  1. Hacky scripting on bamboo such that we have a Deployment or plain plan that actually only adds/replaces one omod file.
  2. We’re doing an “Ebola Distro”, therefore we should fork the refapp distro and change the scripts to include the modules we want (but reuse the scripting to build a .deb, and deploy this) (Pro: probably easy; Con: we’re forked)
  3. We’re doing an “Refapp Distro + Ebola module”, therefore we should have bamboo take the .deb file build by the refapp project, and (hackily?) inject one more omod into it.
  4. Build a generic mechanism that takes { OpenMRS version + list of module+version } (or else a ZIP of war + omods) as input, and knows how to deploy this. (This could produce a .deb and Deploy as we currently do.) The rest of the server setup would be standard (e.g. we might need a base .deb that includes mysql and tomcat)

Does the infrastructure team have time to help us do something less hacky, quickly?

Currently, Maven is used to build the WAR & OMOD files, then a shell script is used to bundle up all the WAR & OMOD files into a .deb package. If we added a step between mvn clean package -DskipTests=true -U and running debian-build.sh we added a build of this .omod artifact and put it in the same place, then the script would build the .deb including ebola.omod.

@ryan does this sound like it would work?

I think 4 would be the best approach, as it would be reusable, but if you are trying to do this quickly I think adding the extra omod before building the debian package would be the easiest and least hacky way. You could take the resulting deb and publish it as an additional artifact along side the refapp deb.


Do you have time to try this out? (Note that the first time you do this it will probably kill the server until I clean up the DB.)

I have set up the steps to make a second Deb package with the added ebola module here (steps are currently disabled). This does rely on an artifact being produced for the ebola module, so when that is successful we should be able to build the new Deb package and deploy it to devtest03.

Hi Ryan,

I sent you some messages on IRC.

To summarize, I updated the Ebola Example Module plan to produce the omod as an artifact. Example: https://ci.openmrs.org/browse/EBOLA-EEM-9/artifact

I had assumed that the deploy to DT03 would be a second stage in this plan but I didn’t see it. Anyway, what’s the next step then?

(I already cleaned up the DB so that things won’t fail after we push the module. In face I installed it manually already to verify that.)

I have set this up an it appears to be working on devtest03. I ended up making a new stage in the distribution build project to build the ref app deb with the ebola module. Let me know how it looks and we can set up triggers and child plans for this to kick off automatically.

1 Like

At first glance, this looks fine. Go ahead and set up the triggers.

It is set up and the next commit should trigger a build and deploy to DTE03.

@darius I have straightened out the automatic building and deploying for this. I ended up adding a second stage to the ebola module to package it. It now builds and deploys on changes from either the ebola module or a new successful build of the refapp distribution.

@ryan this is still not working. I see from https://ci.openmrs.org/browse/EBOLA-EEM that the deb has been deployed (as an aside the version numbers assigned are going to be hopelessly confusing).

However the content that is being deployed must not be containing the new ebolaexample omod because the version that’s there now is still the one I manually deployed days ago.

You can quickly check to see if a new version has been deployed by looking at this page: http://devtest03.openmrs.org:8080/openmrs/ebolaexample/patientsByLocation.page?app=ebolaexample.patientsByLocation => the identifier in each row should be a link to the patient’s ebola overview

Can you please investigate this and test it to make sure it gets properly deployed? Please verify by making an empty commit to the ebolaexample module. (I am many time zones away for the next week, and going back and forth on this every 12 hours is not working.)

I’ve made an empty commit and it builds deploys with the changes you mentioned on the patient’s ebola overview page. As far as versioning goes I’m not sure what would be ideal. By default we can’t grab the build number from the distribution plan, but there may be a way to workaround that? Of course you also have to deal with builds triggering from the ebola module commits as well which could get it out of sync. Right now the versioning being used is in two different places the build project, and the deploy project. What would be the best way to version this?


I actually don’t care at all what we call the versions as long as it doesn’t start with “2.”