I can think of these general approaches (some of which are hacky, but we’re going for quick-to-implement here):
Hacky scripting on bamboo such that we have a Deployment or plain plan that actually only adds/replaces one omod file.
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)
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.
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.
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.
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.
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.
@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.
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?