I know this has been happening every so often.
Let’s starting using the same topic from now on, to simplify who will get involved.
Before reporting a red build, do the following:
- Look the logs. Do they seem like a transient error like ‘timeout’ or similar? Do they complain about lack of disk space? Just try to run it again. They might go green and there’s nothing to report.
- Have you checked any comments on the build? Maybe someone already investigated it. Check the first red one.
- You still have no idea why it failed? Try to run the build again. Maybe some other snapshot got updated, and that will solve the problem. There’s no need to report a broken build if you haven’t tried to rerun it and it was red again. They are not broken, they might be flaky, but not broken.
- Did Reference Application build broke on Travis CI tests? You need to check the logs at travis CI to see what happened.
- Do you have a build that is particularly flaky? Please report. Not as broken, but as flaky. We can take a look on why that’s the case.
- Did a certain build became consistently red since a certain commit? You need to check the commit and see also which snapshots were modifying on that build.
Otherwise, please add it here. Let’s make a single topic, so we don’t get lost on too many mentions.
What does the travis CI logs say?
here is the travis ci logs
i actually hadnt given the bamboo build logs much attention so that i look at the travis ci. Let me try to solve the travis build here
@cintiadr , innitially travis bulld was exceeding the default maximum time .I adjusted it to 30 minutes. But even now it exceeds that , what could be the other solution other than increasing the time further ??.
How much time does that build usually takes? 30 minutes sounds quite a long time for a build, what is making the tests take so long?
@cintiadr , ive tried to trace the actual cause of the failure ,
it was the commit that upgraded the appointmentshedulingVersion to 1.11.0.
On downgrading it back to 1.10.0 , travis patially passes as here.
- The cofing with db=mysql , passes ,
- The config with db=mariaDb ,fails with this error
However before downgrading , both configs fail
Well, maybe @dkayiwa will know who to involve to investigate this one.
@jwnasambu i noticed that you had disabled the CI plan for the reference application distribution. Did you do that intentionally?
@mozzy i did not do anything apart from enabling the build and run https://ci.openmrs.org/browse/REFAPP-OMODDISTRO-9279
@dkayiwa i think it was a problem with the sdk failing to access some dependencies from one of our remote repositories , when you look at this error from the previous travis failure.
[ERROR] Failed to execute goal org.openmrs.maven.plugins:openmrs-sdk-maven-plugin:3.12.4:build-distro (build-distro) on project referenceapplication-package: Execution build-distro of goal org.openmrs.maven.plugins:openmrs-sdk-maven-plugin:3.12.4:build-distro failed: A required class was missing while executing org.openmrs.maven.plugins:openmrs-sdk-maven-plugin:3.12.4:build-distro: org/apache/commons/codec/DecoderException
Am seeing , theres no any commit that was done , yet now travis build is succesfull and yet last friday i was strugling with correcting the build failure. and it was giving me thiss error.
Anyway weldone ,i hope you dint use some magic that some of us dont have
Unfortunately am also just reading this for the first time,on the repo read me
### Running ui-tests locally:
By default tests are run with Firefox 42.0 ([download here](https://ftp.mozilla.org/pub/firefox/releases/42.0/)), so please be sure to have it installed. Also tests are run against [https://qa-refapp.openmrs.org](https://qa-refapp.openmrs.org/) so confirm it is accessible from your machine. It is also possible that tests start failing due to qa-refapp being redeployed. If it happens, please wait for qa-refapp to be available again and run tests again.
Am , just getting to know now that the ui-tests are ran against the qa-server. Probably on friday the server was down or being re-deployed.