since openmrs-distro-referenceapplication is the one breaking,did you mean this Travis CI - Test and Deploy Your Code with Confidence
Could this mean changing the web url value sited in test-travis-ci.properties file to point to the local instance. Or both present in test.properties and test-travis-ci.properties files. If this is true how will travis resolve this
For this case travis will depend on the local instance whose properties are added to test-travis-ci.properties file
1 Like
you never have to change test-travis-ci.properties file at all since that’s never used at all locally except by travis ci, for your local testing use test.properties file rather.
I recommend you use the data in the standard dataset in your tests and deploy the same dataset locally but that should be automatically done for your if you are using distro’s approach to deploying your local instance. Our travis on master is passing and so you should be checking why your specific test passes locally and not on travis!
1 Like
travis shows that a bunch of tests are failing!!
Am working towards this ideal! I will share my findings on this
Thanks members for this wordefull milestone, Been little off apologies, cc @k.joseph this makes more sense recommending to use the standard data set hopefully, this may be the cause of failure of our tests locally, Will share my finding according to the suggestions above
1 Like
Have been debugging for a good number of hours on this issue though not yet registered a smile. Some thing to notice; All the tests fail on remote encounter with Travis.
Here are the things I would like to be enlighten as I dig into this concern more;
Could ignoring setting location attribute in test-travis-ci.properties file on master be the cause for the failing incoming pr’s since this attribute is mandatory for the login instance
I came across this post with a similar concern but it seemed the commiter had some changes that travis could not resolve. I have changed travis to load from the local instance while the local server is running but still CI jobs fails.
Changing the default chrome driver sited in the uitestframework module to a custom one(downloaded driver) makes the tests pass in the IDE otherwise tests fails with default driver
Travis is redirected to resolve builds based on openjdk8 in the file named .travis.yml in distro. However, does this cater for all the consolidated updates and releases under jdk8 as per this oracle wiki Or the one present in that file targets a specific release probably the one that was current by then.
@sharif any finding on this as well.
cc: @k.joseph @herbert24
Recently i encountered such an error and i got it successfully after upgrading chrome driver to the exact version of chrome , inotherwords we should have the verson of chrome driver compatilble with your running chrome browser
Do your tests pass locally 
Absolutely
As for travis, it’s running a specific firefox version that works well with the embedded webdriver. so except if u try forcing the properties to use chrome, all should be well and i can already see master branch running with out issues
according to the logs, u could be have messed up the travis test properties file, let me take a look
1 Like
O yeah, i found it. U got the file messed it along the url line,
catch that at:
1 Like
Oops! Should I also omit the location property
it existed and not your trailing change, it’s needed. just reset the file to its origin and ensure its out of your PR and you will be ready to go
Well have made numerous changes on this file to see the right way out, however I added this property in one of the previous commit that I made though I rebased these commits and that is why its not being reflected in the recent commit as a new change. Could you take a look on this file on the upstream master
This asserts this to be true
Then we need to add this property in upstream master
which property are you talking about? master has the right file which is why your Pr change preview tracks the change