openmrs-module-referenceapplication build is failing requiring reporting api 0.9.5, but openmrs-module-reporting master builds 0.9.7. Any ideas on a fix? Thanks.
Everyone, especially @dkayiwa @wyclif @raff,
How is it that the reference application module build has been broken since August 5, and nobody has noticed or fixed it?
@michael, @burke, etc, is there a quick way that we could have, say the scrumon and/or scrumoff commands automatically also say what the currently-broken bamboo builds are? Alternately we could have the bot list out currently-broken builds every hour.
I think we need to be pushier about notifying what is currently broken.
1 Like
It is probably possible to hack together a reminder system.
For the moment, I’d also encourage everyone that cares about broken builds to configure their IRC clients (how to do this varies by client) to alert on the string "New from OpenMRS ci", to get alerted on each broken build notification.
If we had some things like:
(loaded dynamically from https://ci.openmrs.org/plugins/servlet/wittified/build-status/RA-RA) placed in a commonly-seen location around our web presence somewhere would it be helpful? (Assuming we could decide which builds to pay attention to.)
That would be nice.
I’d also like us to have some sort of progressively more noticeable message (on IRC) when a build has been broken for more than 24 hours.
(I would typically ignore the brown build messages if I’m not actively working on something.)
According to this: I asked @tmueller regarding this. @raff started on ignoring the tests for now since @tmueller is on vacation.
But that being said, the rate at which i have been seeing failures for the
reference application builds was too high that it was easy to just ignore
them for a while. 
1 Like
Yes, when there are too many build failures, it becomes easy to stop paying attention.
That said, this is an example of a bad practice that I don’t want us to fall into: it is not the job of a separate QA team to deal with everything to do with tests. And the dev team’s role does not end when they have written code and “thrown it over the wall”.
Particularly, anyone who is working on OpenMRS more than 50% time in any role should (a) look at CI at least daily, and (b) if anything is broken more than transiently, then take steps to get it fixed. (Often that just means verifying that someone else is dealing with it.)
But we should not have any builds broken for weeks without /dev/5s taking action.
1 Like
The reporting-0.9.5 vs reporting-0.9.6-SNAPSHOT was occurring because even though the HEAD of the master branch of distro-referenceapplication is at version 2.3-SNAPSHOT, there was a released 2.3 version of distro-referenceapplication in OpenMRS Nexus, so although reporting had been updated to the correct version number in the HEAD of distro-referenceapplication, the older deployed 2.3 version was taking precedence.
We need to be carefully about avoiding downgrading version numbers, and, if we must, making sure that any necessary deployments are cleaned up in Nexus. I’m guessing this was some sort of automated release gone bad and not cleaned up after?
Anyway the reference app and reference metadata builds passed after I deleted the offending 2.3 version of distro-referenceapp from Nexus. Maybe the actual distribution will pass now as well.
1 Like