Do we have a “bleeding edge” CI server for the reference app… ie, one that deploys the snapshots of many/most of the modules related to the reference app? I went to int02.openmrs.org, but this was running primarily non-snapshot versions.
Use case: I was developing on my local copy of the PIH-EMR and I noticed stray text saying “null” that showed up on the clinician-facing dashboard. I tracked this down to a recent refapp-related commit in the coreapps module. The fix was easy, but I could neither 1) confirm that the error was present in the Ref App distro nor could I 2) confirm that my fix worked in the Ref App distro without breaking anything else. I could only test in the PIH-EMR context. (Assumedly also the bug would have been caught earlier if there had been a Ref App server where it manifest itself).
I fear the answer to this question is no and from all the chatter recently we neither have a spare server space for this nor resources to maintain it. Another vote for really working on our fundraising to support these things!
The issue which @mogoodrich fixed was a due to a recent commit which introduced a way to delete a patient in the reff all (RA-1089 ) and the code was written me. Apologies. It’s all sorted now though
We were wondering exactly as to when these updated are actually shown on the demo server. Having a ‘bleeding-edge’ server which deploys OpenMRS would be really useful. New issues/improvements with respect to recent commits could be seen, discovered and suggested by all the Devs, instead of only those who were working on it.
Unfortunately, we don’t have the luxury of having extra/additional servers at this point & time. That said, I think we still need to decide what should be running on our integration & quality assurance servers. I could easily see us deciding that, for the reference application, we want to test any new commits to any included modules (your “bleeding edge”) by default. If a module was incorporating new & funky features not intended for upcoming versions of the reference application, then we’d try to do those in a branch or do them in master & create a version branch that CI could follow (picking up anything backported to that version branch).
@darius, do you have an opinion about this? Don’t we want our automated testing to be testing any new commits to core or included modules?
I thought int02.openmrs.org runs snapshot version of modules. Because i can remember working on an RA ticket and soon as my code was merged i could see the changes here, int02.openmrs.org
I’m working on getting devtest05 reconfigured to serve as uat-refapp.openmrs.org (I assume this will eventually get renamed to uat02, but the actual server name doesn’t matter… we only need to remember uat-refapp), which is what we’d like to be used for release testing. That would free up integration testing (int-refapp.openmrs.org currently on int02.openmrs.org) to focus on integration testing with snapshots rather than trying to serve for release testing as well.
It would definitely be nice to have a server running the latest snapshots of everything in the reference application. Usually this is lower priority because during the typical development cycle the reference application is mostly made up of snapshots, and so the qa-refapp server (formerly devtest02) is what you want here.
It’s only “while we are releasing refapp modules in preparation for the refapp release” that this isn’t the case (as Mark commented). Normally this is only supposed to be a ~2 week process, however this time we have been delayed for various reasons (CIEL issues, not having the right UAT server, and some more), and we’ve been in the “doing the release” state for over 2 months.
So…if we think that we’ll be able to clean up our process and be able to the future refapp releases faster, then I wouldn’t necessarily change things.
The alternative, to try to get the most coverage out of the fewest servers is:
int-refapp runs the current refapp build (not necessarily snapshots), and automated tests are run against it
this doesn’t even need to be a fixed server, if we could rewrite our CI scripts to run this on a disposable docker container
qa-refapp runs snapshots of all refapp modules against a released version of openmrs-core.
when we’re doing refapp release testing (e.g. hopefully for 3 weeks every 6 months), we use a UAT server to run the refapp release candidate (similar to int-refapp, but manually deployed)
@mogoodrich I haven’t really read through the comments here but as I was looking up stuff, I stumbled across uat01.openmrs.org:8080/openmrs/ which I think sort of behaves like the bleeding edge server. I can see my addition in RA-1089 showing up, as well as Larry’s ticket and everything I worked on 2-3 months ago. What do you think?
