Whenever I try to QUnit-Test on Travis the build fails with a PhantomJS Timeout Error.
See: https://travis-ci.org/misantronic/frameWreck/builds/38939015 from line 86.
On my local system everything just works fine.
Its actually loading all the sources (QUnits.js and my js-module) but as soon as the test() function is invoked, it fails.
I found some topics about this issue, but these were because of the grunt version number (<0.4). Thats not the case.
Related
I've got an interesting problem with Grunt-Concurrent. When a registered task such as Uglify or Karma runs without errors everything is fine. But if Uglification or Karma tests fail then Grunt-Concurrent will continuously loop until the error is fixed. This was annoying with Uglify but with Karma unit tests it's really hard to have it looping until the bug is fixed.
Any ideas of how to solve this?
I can't really provide examples of our exact set up.
It will just keep running with this message until the unit tests all pass:
Running "watch:karma" (watch) task
Waiting...
Running "karma:unit:run" (karma) task
Firefox 39.0.0 (Mac OS X 10.10.0) it should work should work FAILED
Expected true to be false.
...: Executed 2 of 2 (1 FAILED) (0.007 secs / 0.004 secs)
Warning: Task "karma:unit:run" failed.
It then runs it over again and again and again.
Looks like the issue was actually with grunt-contrib-watch and once I started going down that path I found the answer.
I found this great SO question: Prevent `grunt-watch` from looping when there is a syntax error in less files?
I found that by changing spawn: true that it no longer loops like it used to.
Simple tests are timing-out intermittently on CircleCi. This only happens on CircleCi, locally on OSX, all testing is fine. Anyone having success with CircleCi specifically?
Running tests should be straightforward, but no one at CircleCI, or at the velocity forum have been able to solve this.
I've used the simple example tests from sanjo:jasmine. Intermittently, velocity hangs and goes to timeout. No errors. Nothing informative in logs. Strangely it did work once on CircleCi, and then never again.
The test command is simply:
meteor --test
The output I get doesn't print any tests:
stream error Network error: ws://localhost:3000/websocket: connect ECONNREFUSED
[[[[[ ~/app ]]]]]
=> Started proxy.
=> Started MongoDB.
=> Started your app.
=> App running at: http://localhost:3000/
In the .meteor/local/log/jasmine-client-unit.log this is the last line:
Chrome 38.0.2125 (Linux): Executed 0 of 0^[[32m SUCCESS^[[39m (0 secs / 0 secs)
^[[1A^[[2KChrome 38.0.2125 (Linux): Executed 0 of 0^[[31m ERROR^[[39m (0.023 secs / 0 secs)
I confirmed that the versions are the same Meteor 1.03.2, Node 0.10.33, Phantomjs 2.0.0, Chrome 40. Sorry that I can't provide a reproducible repository, it's a very intermittent error likely related to environment.
Try meteor --test --once
The once might be the reason it's not finishing up
edit
It turns out that jasmine end to end testing recommends webdriver as well. So my advice below should still apply for jasmine.
/edit
What framework? If it is cucumber, the issue is the phantomjs version that gets installed doesn't install the right binary for some reason.
For that reason, in CI, you need to install phantom and set the path as an environment variable.
npm install -g phantomjs
export PHANTOM_PATH=`which phantomjs`
This will tell webdriver to use your path of the correctly installed binary instead of the wrong version.
We should really just fix Cucumber.js to not fail silently.
The other error you are seeing about websockets is just --test not connecting right on startup, it doesn't affect anything.
I'm really just looking to pick the community's brain for some leads in figuring out what is going on with the issue I'm having.
I'm writing a MR job with RHadoop (rmr2, v3.0.0) and things are great -- IO with HDFS, mapping, reducing. No problems. Life is great.
I'm trying to schedule the job with Apache Oozie, and am running into some issues:
Error in mr(map = map, reduce = reduce, combine = combine, vectorized.reduce, :
hadoop streaming failed with error code 1
I've read the rmr2 debugging guide, but nothing is really getting to the stderr because the job fails before anything even gets scheduled.
In my head, everything points to a difference in environments. However, Oozie is running the job as the same user that I'm able to run everything with via cli, and all of the R environment variables (fetched with Sys.getenv()) are the same, excepting there's some additional class path stuff set with Oozie.
I can post more of the OS or Hadoop versions and config details, but sleuthing some version-specific bugs seems like a bit of a red herring as everything runs fine at the command line.
Anybody have any thoughts what might be some helpful next steps in hunting this beast down?
UPDATE:
I overwrote the system function in the base package to log the user, the host name of the node, and the command being executed before the internal call to system. So before any system call is actually executed, I get something like the following in the stderr:
user#host.name
/usr/bin/hadoop jar /usr/lib/hadoop-mapreduce/hadoop-streaming-2.2.0.2.0.6.0-102.jar ...
When ran with Oozie, the command printed in the stderr fails with an exit status of 1. When I run the command on user#host.name, it runs successfully. So essentially the EXACT same command with the SAME user on the SAME node fails with Oozie, but runs successfully from cli.
I'm using Plone 4.1 and trying to run bin/buildout in a fresh directory, having just managed to get python bootstrap.py --distribute to work. bin/buildout runs along fine for a couple of minutes, downloading various distributions, then crashes with the following report:
Getting distribution for 'plone.recipe.zope2instance==4.1.7'.
Got plone.recipe.zope2instance 4.1.7.
... (many distributions omitted for brevity) ...
Getting distribution for 'zope.container==3.11.2'.
Got zope.container 3.11.2.
Getting distribution for 'zope.configuration==3.7.4'.
error: Not a recognized archive type: /Users/Jon/.buildout/downloads/dist/zope.configuration-3.7.4.zip
An error occured when trying to install zope.configuration 3.7.4. Look above this message for any errors that were output by easy_install.
While:
Installing.
Getting section instance.
Initializing section instance.
Installing recipe plone.recipe.zope2instance.
Getting distribution for 'zope.configuration==3.7.4'.
Error: Couldn't install: zope.configuration 3.7.4
It looks like the important error message is: Not a recognized archive type: /Users/Jon/.buildout/downloads/dist/zope.configuration-3.7.4.zip
Incidentally, I tried simply re-running bin/buildout and it picked up in a new place, starting with:
Getting distribution for 'zdaemon==2.0.4'.
Got zdaemon 2.0.4.
Getting distribution for 'pytz==2011g'.
Got pytz 2011g.
...and so on. Can I just keep retrying the script until it successfully get all the stuff that it needs?
Also, I tried running bin/buildout for version 4.2 in another directory, and that seemed to work okay.
EDIT The second time I ran bin/buildout it completed without crashing. However, I did a search of the output and it never once downloaded anything with "configuration" in it's name. So what is going on???
EDIT Just for good measure I tried running bin/buildout a third time and it exited quickly after printing the single line "Updating instance."
You're fine. I suspect you have a less than ideal network connection and/or that PyPI is having problems (one of your other posts was about network related issues as well, I think).
The error you saw is that it's tried to download a zip file that's been corrupted, and so it fails to extract the zip file. On your second attempt, it downloaded it successfully.
I'm supposed to run some jbehave(automated) tests in bamboo. Once the tests run I'll generate some junit compatible xml files so that bamboo could understand the same. All the jbehave tests are ran as part of a script, because I need to run the jbehave tests in a separate display screen(remember these are automated browser tests). Example script is as follows.
Ex:
export DISPLAY=:0 && xvfb-run --server-args="-screen 0, 1024x768x24"
mvn clean integration-test -DskipTests -P integration-test -Dtest=*
I have one more junit parser task which points to the generated junit compatible xml files. So, once the bamboo build runs and even if all the tests pass, I get red build with the message "No failed tests found, a possible compilation error occurred."
Can somone please help me on this regard.
Your build script might be producing successful test reports, but one (or both, possibly) of your tasks is failing. That means that the failure is probably* occurring after your tests complete. Check your build logs for errors. You might also try logging in to your Bamboo server (as the bamboo user) and running the commands by hand.
I've seen this message in the past when our test task was crashing halfway through the test run, resulting in one malformed report that Bamboo ignored and a bunch of successful reports.
*Check the build log to make sure that your tests are indeed running. If mvn clean doesn't clean out the test report directory, Bamboo might just be parsing stale test reports.
EDIT: (in response to Kishore's links)
It looks like your task to kill Xvfb is what is causing the build to fail.
18-Jul-2012 09:50:18 Starting task 'Kill Xvfb' of type 'com.atlassian.bamboo.plugins.scripttask:task.builder.script'
18-Jul-2012 09:50:18
Beginning to execute external process for build 'Functional Tests - Application Release Test - Default Job'
... running command line:
/bin/sh
/tmp/FUNC-APPTEST-JOB1-91-ScriptBuildTask-4153769009554485085.sh
... in: /opt/bamboo-home/xml-data/build-dir/FUNC-APPTEST-JOB1
... using extra environment variables:
<..snip (no meaningful output)..>
18-Jul-2012 09:50:18 Failing task since return code was 1 while expected 0
18-Jul-2012 09:50:18 Finished task 'Kill Xvfb'
What does your "Kill Xvfb" script do? Are you trying something like pkill -f "[x]vfb"? pkill -f silently returns non-zero if it can't match the expression to any processes.
My solution was to make a 'script' task:
#!/bin/bash
/usr/local/bin/phpcs --report=checkstyle --report-file=build/logs/checkstyle.xml --standard=PSR2 ./lib | exit 0
Which always exits with status 0.
This is because PHP code sniffer return exit status 1 when only 1 coding violation (warning / error) is found which causes the built to fail.
Turns out to be a simple fix.
General bamboo behavior is to scan the entire log and see for any failure codes(1). For this specific configuration i had some 6 scripts out of which one of them was to kill the xvfb(frame buffer). For some reason server is not able to kill xvfb and that task was returning a failure code. Because of this, though all the tests passed, bamboo got one of this error codes from previous tasks and build was failing.
Current fix is to remove the task which kills xvfb and the build went green! \o/.