@raff is there a way to “roll back” to the version of a module references in the distro?
Example use case:
PIH distro uses allergyui-1.5
I wanted to test the latest version of allergyui, so I started watching the allergyui module, build and deployed the latest, which upgraded my local distro to use 1.6-SNAPSHOT
It turns out that the latest version of allergyui isn’t working with OpenMRS 1.10.x, so this is breaking our dashboard
I can’t build the old 1.5 version of allergyui locally because of dependency ■■■■.
The only workaround I found was to manually download allergyui-1.5 from modulus and manually swap it out in the modules directory of that distro.
Hmm, it also looks like even if I follow the above steps, when I next do a mvn openmrs-sdk:run, it will still update to version 1.6-SNAPSHOT, even if I select “n” when prompted about updating the module. I think because I am still watching the allergy ui module?
This may be correct behavior, but we do need a way to “unwatch” a module then.
What would be the implications of this? Just that tomcat is listening on the debug port?
Literally “SDK” means software developers kit, and anyone who is doing development should want to be able to debug. In that sense I vote for doing it by default. (I always configure it on my sdk servers.)
However if we intend for the SDK to be used to deploy production instances this would be bad. @burke, and @rafal, what are you envisioning on this front?
Yes, @darius summed up my thoughts exactly… if it truly is just for developers, having it by default makes sense. But, yes, not such a good idea if we envisioned it being used to set up production instances.
I don’t envision SDK being used directly in production. I’d like it to be used to provision distributions that is to create docker files out of distro properties, which can be used in production.
I guess I’m fine with running in the debug mode by default. One will only have to remember to change 2 ports (tomcat and debug port) instead of just one tomcat port when wanting to run 2 or more instances at the same time.
Hmm, having to remember to specify two custom ports when running multiple instances is a drawback. Any thoughts/ideas anyone around a convention around this that might make it reasonable to do?
Would it work to have the default value of the debugging port be decided based on the value given for tomcat? (E.g. tomcat at 8081 means debugging on 5081?)
Or could we make it such that specifying a debugging port implies debug=true?
Taking a step back, I think the best solution would be to have the setup server wizard ask
If you want to enable remote debugging, specify the port number here (e.g. 5000). Leave blank to disable debugging. (Do not do this on a production server.) [default: no debugging]
That way it’s trivially easy for devs to add remote debugging to every SDK server they setup, but it’s also easy to skip this.
There is a slight (major) problem. If the CI build above is to test to make sure that Ref App builds then we need a way to run (integration) tests. Currently all the CI build does is to create Docker containers with Ref App and MySQL. I don’t see the point of this.
To test I will have to pull the distro from git with the pom to run mvn clean install etc.
It will be nice if we could do:
mvn openmrs-sdk:setup -D:serverID -Drefappversion=2.4
mvn openmrs-sdk:run -DserverId
mvn openmrs-sdk:test -DserverId -Drefappversion=2.4
Sorry, can’t remember the exact way to specify the distro.