# openmrs-module-referenceapplication build failing

**URL:** <https://talk.openmrs.org/t/openmrs-module-referenceapplication-build-failing/2907>\
**Category:** Development\
**Created:** [August 28, 2015, 4:49pm UTC](https://talk.openmrs.org/t/openmrs-module-referenceapplication-build-failing/2907 "2015-08-28T16:49:03Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![jdegraft](https://talk.openmrs.org/user_avatar/talk.openmrs.org/jdegraft/32/1049_2.png) [@jdegraft](https://talk.openmrs.org/u/jdegraft)\
**Post date:** [August 28, 2015, 4:49pm UTC](https://talk.openmrs.org/t/openmrs-module-referenceapplication-build-failing/2907/1 "2015-08-28T16:49:03Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![darius](https://talk.openmrs.org/user_avatar/talk.openmrs.org/darius/32/8082_2.png) [@darius](https://talk.openmrs.org/u/darius)\
**Post date:** [August 28, 2015, 8:57pm UTC](https://talk.openmrs.org/t/openmrs-module-referenceapplication-build-failing/2907/2 "2015-08-28T20:57:34Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![michael](https://talk.openmrs.org/user_avatar/talk.openmrs.org/michael/32/15070_2.png) [@michael](https://talk.openmrs.org/u/michael)\
**Post date:** [August 28, 2015, 9:01pm UTC](https://talk.openmrs.org/t/openmrs-module-referenceapplication-build-failing/2907/3 "2015-08-28T21:01:13Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![michael](https://talk.openmrs.org/user_avatar/talk.openmrs.org/michael/32/15070_2.png) [@michael](https://talk.openmrs.org/u/michael)\
**Post date:** [August 28, 2015, 9:23pm UTC](https://talk.openmrs.org/t/openmrs-module-referenceapplication-build-failing/2907/5 "2015-08-28T21:23:04Z")

</div>

If we had some things like:

[![Build Status](https://ci.openmrs.org/plugins/servlet/wittified/build-status/RA-RA)](https://ci.openmrs.org/browse/RA-RA)

(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.)

---

<div class="post-metadata">

**Author:** ![darius](https://talk.openmrs.org/user_avatar/talk.openmrs.org/darius/32/8082_2.png) [@darius](https://talk.openmrs.org/u/darius)\
**Post date:** [August 28, 2015, 10:24pm UTC](https://talk.openmrs.org/t/openmrs-module-referenceapplication-build-failing/2907/6 "2015-08-28T22:24:44Z")

</div>

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.)

---

<div class="post-metadata">

**Author:** ![dkayiwa](https://talk.openmrs.org/user_avatar/talk.openmrs.org/dkayiwa/32/179_2.png) [@dkayiwa](https://talk.openmrs.org/u/dkayiwa)\
**Post date:** [August 29, 2015, 6:15pm UTC](https://talk.openmrs.org/t/openmrs-module-referenceapplication-build-failing/2907/7 "2015-08-29T18:15:39Z")

</div>

According to this:

> [@CI Build is unable to connect to host](https://talk.openmrs.org/t/ci-build-is-unable-to-connect-to-host/2636/4):
>
> I can see that the problem disappeared, Thanks, @cintiadr!!

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. 🙂

---

<div class="post-metadata">

**Author:** ![darius](https://talk.openmrs.org/user_avatar/talk.openmrs.org/darius/32/8082_2.png) [@darius](https://talk.openmrs.org/u/darius)\
**Post date:** [August 31, 2015, 3:14am UTC](https://talk.openmrs.org/t/openmrs-module-referenceapplication-build-failing/2907/8 "2015-08-31T03:14:13Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![mogoodrich](https://talk.openmrs.org/user_avatar/talk.openmrs.org/mogoodrich/32/3324_2.png) [@mogoodrich](https://talk.openmrs.org/u/mogoodrich)\
**Post date:** [August 31, 2015, 5:48pm UTC](https://talk.openmrs.org/t/openmrs-module-referenceapplication-build-failing/2907/9 "2015-08-31T17:48:54Z")

</div>

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.
