Bahmniapps: 2 tests failing in the release-0.81 branch

Hello all,

I checked out and attempted to build the HEAD of the release-0.81 Bahmni branch, and noticed that two tests are failing. I’ve pasted the two failing messages below and could potentially look into them, but is there a CI Bahmni pipeline anywhere I can look at? Is it set up to run against just the master branch, or also some of the release branches? I’d like to at least be able to determine if this is just an issue for me, or if it a curent failing build.

Thanks, Mark

mogoodrich@mogoodrich-ThinkPad-T510:~/bahmni-code/openmrs-module-bahmniapps/ui$ grunt test
Running "karma:unit" (karma) task
WARN [watcher]: Pattern "/home/mogoodrich/bahmni-code/openmrs-module-bahmniapps/ui/app/components/offline/offline.min.js" does not match any file.
INFO [karma]: Karma v0.12.37 server started at http://localhost:9876/
INFO [launcher]: Starting browser Firefox
INFO [Firefox 45.0.0 (Ubuntu 0.0.0)]: Connected on socket 93KUyBw6sqRd0InooE_T with id 22471018
WARN: 'Deprecation warning: moment construction falls back to js Date. This is discouraged and will be removed in upcoming major release. Please refer to for more info.'
Firefox 45.0.0 (Ubuntu 0.0.0) programService test updatePatientProgram FAILED
	Expected { dateEnrolled : '2016-01-01T00:00:00-0500', states : [  ], uuid : 'Some UUID', dateCompleted : '2016-01-11T19:00:00-0500', outcome : null, attributes : [ { attributeType : { uuid : '079b73c6-b854-11e5-9584-0800274a5156' }, value : '123', uuid : '6ccf5c9c-9f8c-4e46-b40b-c203b033f6d7' }, { attributeType : { uuid : '07ae82e4-b854-11e5-9584-0800274a5156' }, value : '2016-01-12T00:00:00.000+0000', uuid : '12cac096-ac84-419f-88c3-f140a3c13d98' } ] } to equal { attributes : [ { uuid : '6ccf5c9c-9f8c-4e46-b40b-c203b033f6d7', attributeType : { uuid : '079b73c6-b854-11e5-9584-0800274a5156' }, value : '123' }, { uuid : '12cac096-ac84-419f-88c3-f140a3c13d98', attributeType : { uuid : '07ae82e4-b854-11e5-9584-0800274a5156' }, value : '2016-01-12T00:00:00.000+0000' } ], states : [  ], outcome : null, dateCompleted : '2016-01-12T05:30:00+0530', dateEnrolled : '2016-01-01T00:00:00+0530', uuid : 'Some UUID' }.
Firefox 45.0.0 (Ubuntu 0.0.0) ManageProgramController get maximum allowed program enrollment date for edit flow Should return minimum start date of states FAILED
	Expected '2015-06-30' to equal '2015-07-01'.
Firefox 45.0.0 (Ubuntu 0.0.0): Executed 1360 of 1373 (2 FAILED) (skipped 3) (20.761 secs / 19.409 secs)

=============================== Coverage summary ===============================
Statements   : 64.5% ( 8370/12977 )
Branches     : 54.01% ( 3088/5717 )
Functions    : 56.21% ( 2207/3926 )
Lines        : 64.51% ( 8342/12931 )
Warning: Task "karma:unit" failed. Use --force to continue.

Aborted due to warnings.

hi @mogoodrich, this looks like timezone related issue. It works fine in IST. We will need to investigate that. Feel free to provide us a PR if you fixed the issue.

Bahmni’s CI is available here. The credentials are available here

Thanks @bharatak - let us know if there is a mingle card we can refer to for this.

Cheers, Mike

A time zone issue does make sense. To confirm, at least one of them is also failing for me (in EDT) when running against the master branch.


I think it’s unnecessary to have a mingle card for a trivial fix that is not user visible. In this case you should feel free to just write the pull request and send it.

I think @mseaton was referring to the failing test due to being in a different timezone, which may or may not be trivial depending on whether is it just the test that is specific to IST or whether there is a larger problem.

Take care, Mark

Let me rephrase:

Having a mingle card attached to the commit is not very important for a change that only touches test code.

And if you run into an incorrectly-written test that fails for timezone reasons, there is no need to wait for a round-trip Boston-India conversation (and it would set a bad precedent to expect this).

So in this situation you don’t need to refer to a mingle card.

In the spirit of not adding unnecessary process dependencies, I’d point out that you can always send a PR first, and then amend the commit message to refer to a mingle card later, if that works better for you in a particular case. (Basically, if you’re confident that something is a bug, and you prefer to write code before someone verifies it and creates a mingle card, you can do this.)


Sorry for the confusion here, too many different thread going on. I totally agree. In this case, we have not fixed the issue and don’t immediately plan to address it, so we were just suggesting a mingle card was created to track it.


FYI - I have issued a follow-up pull request to try to address this here: