Hello all–many of the ref app distro module (EMR-API, AppUI, etc) builds are failing for us because they still rely on version 2.4-SNAPSHOT of the distro module, while the current version is 2.5-SNAPSHOT (and so 2.4-SNAPSHOT is no longer in the maven repo).
They are passing on ci.pih-emr.org, but I’m assuming that is because the 2.4-SNAPSHOT is still in the CI server’s local repo. In our build, we clean out the local on our CI server nightly (so that we uncover these kinds of issues sooner rather than later).
This was happening the night before last as well, but then @dkayiwa rolled back the distro module to 2.4-SNAPSHOT and it fixed. But looks like it was rolled up to 2.5-SNAPSHOT again yesterday.
Have we defined a the process here? I know we’ve never been able to come up with a “clean” way to handle this dependency problem, so I don’t have any great suggestions off the top of my head. I think we can live with some temporary instability as long as it is on the order of hours, not days.
So, the problem that emrapi explicitly says distro.version=2.4-SNAPSHOT.
I guess we just need to update that to be 2.5-SNAPSHOT (or 2.4?), and to do the same in a bunch of modules.
I would think that the “process” in this case is just to notice that the CI builds fail and fix them, right? (Though maybe some are more complex than this.)
@darius@dkayiwa is it possible to maintain the last snapshot of any released modules, so that those implementations that depend on it can keep working even when the version is released?
@darius That requires continous monitoring and at times we have had to troubleshoot issues when that was the main issue, yet if the snapshot was maintained on releasing the module then life would proceed as before.
So I also need to increment the versions of (at least certain) modules listed in the distro snapshot to use the latest snapshot versions of those modules, since the most recent released versions now rely on the no-longer-available 2.4-SNAPSHOT… this is correct, right?
@darius So just bringing this back up, we faced this problem again today in our local distro platform that had appui, emrapi, referenceapplicationmetadata-omod and referenceapplication-omod breaking because they depended on 2.4-SNAPSHOT of the distro which is no-longer available.
@ssmusoke, what exactly is breaking? I would expect that:
(1) you can change your distro to inherit from reference application 2.4 (final) rather than 2.4-SNAPSHOT, now that the release has happened.
(2) appui, emrapi, etc, are already built (and released) so you should be able to just include released versions of them
@darius In the distro platform the modules are loaded from Nexus, so the dependencies for the built versions are pointing to 2.4-SNAPSHOT which does not exist as I cleaned out my local Maven repo to reproduce the error. I have had to bump up the versions to the ones pointing to 2.5-SNAPSHOT
@ssmusoke is correct. The most recent released version of EMR-API (and a few other modules) rely on distro 2.4-SNAPSHOT, so there no longer a way to build anything other than the latest snapshot version of these modules (or build anything that depends on anything but the latest snapshot version of these modules) unless you happen to have distro 2.4-SNAPSHOT cached in your own local maven repo.
This is a mess.
Some thoughts I’ve had:
Keep old snapshot versions of the distro module in our maven repo (we haven’t determined yet if this level of granularlity is possible–ie to keep old snapshots of one artifact, but not another)
Abandon the whole idea of having modules import version numbers from the distro and instead set up an automated process in our build pipeline so that key modules automatically update to the latest versions of other key modules during the build. We have something like this in place at PIH.
I keep meaning to give more thought to this latter approach but then I get pulled in other directions…
@ssmusoke, so (after removing refapp 2.4-snapshot from my local maven rapo) I am able to build the master branch of this repo, but when I try to to build 1.0.4, it fails with the error you describe.
From a dev workflow perspective, what’s the reason that you’re trying to build the already-released version of your distro? I.e. doesn’t the already-built distro live somewhere? And thus is there a workaround?
I agree. Someone has to invest the time to explore options. Is the “keep snapshot versions of the distro pom” a viable quick-fix? (If not more time must be invested in changing the whole process around.)
Does someone want to step up and own this investigation and task? (I guess, for example, @mogoodrich would be happy to help someone do this, but doesn’t have time to take the lead.)
PS- I also notice that in this released version of your distro you are referring to snapshot builds of openmrs-core coreapps, and xforms. This is generally bad practice, but I presume you have reasons for this. Anyway, it’s not the point of this thread
@darius I have just pushed the fix to the master branch after discovering the issue so that is why it compiles. The openmrs-core, core-apps and xforms snapshot versions have specific fixes that we need for our implementations which have not been released in versions while appui, emrapi, referenceapplication and referenceapplicationmetadata are to ensure the platform can build
