Sorry for being late to comment on this thread! We should clarify what outcomes we are aiming to achieve here, and for how long we want to commit to them.
Historically, we have CI build and run automated tests on each commit to the reference application distro. As Maurya points out, we are moving the refapp distro to be based on the latest 2.x platform release. In theory the only thing we have to do here is to change one value in pom.xml of the reference application distro to indicate this new version of openmrs-core, and the existing CI plans will automatically be using platform 2.0. @maurya, you can do this yourself. (In practice things might break if the int/qa servers don’t have Java 8. In this case the infra team will need to help.)
Further @ssmusoke is asking that OpenMRS maintains CI plans that run the reference application against platform 1.x. We never did this before (e.g. when switching the refapp from 1.9.x to 1.10.x to 1.11.x), but given the larger changes from 1.x to 2.x I sort of agree with doing it, but let’s not forget that is a new thing to impose on the OpenMRS community.
Practically, I guess what are talking about is to take the current reference application modules + an older version of openmrs-core, and run the current refapp functional test suite. But what happens if the tests break? Are we saying that reference application package must be able to run against platform 2.x and 1.11 indefinitely? I don’t agree with making that commitment.
Right now, groups that build other distros from reference application components run their own CI servers, and have their own test suites to ensure that their configurations keep working even as the components evolve. E.g. PIH build its EMR on platform 1.10 with many refapp components, and Bahmni uses platform 1.12 with a few refapp components. And when something breaks for one of them they’ll raise that issue on OpenMRS channels and find a way to resolve it. Uganda should take the same approach: you are building your own distro, so that distro needs its own test suite, run in its own CI. And when someone else makes a change that breaks Uganda’s CI you should share this info and work out a solution with them.
As far as the individual components that make up the reference application go, these will continue to work on platform 1.x as long as feasible (and I’m practice that will be a long time), and if something like the coreapps module we to go to platform 2.0, that would be discussed at length.
So, if you want to set up an OpenMRS CI plan like Daniel suggests, you can try this, but I’m uncomfortable committing the community to keeping this CI plan green.