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.
Related
I'm trying to run my first deno script which is pretty much from the denoDB docs, it just tries to connect to a database with a SQLite3 connector (I'm on a Macbook pro so it should be installed):
import { Database, SQLite3Connector } from 'https://deno.land/x/denodb/mod.ts';
const connector = new SQLite3Connector({
filepath: './db.sqlite',
});
export const db = new Database(connector);
I'm running deno run api/db.ts and I get this error after a few successful downloads:
Download https://deno.land/std#0.149.0/encoding/hex.ts
Download https://deno.land/std#0.149.0/hash/_wasm/lib/deno_hash.generated.mjs
error: Import 'https://dev.jspm.io/inherits#2.0' failed: 500 Internal Server Error
at https://raw.githubusercontent.com/Zhomart/dex/930253915093e1e08d48ec0409b4aee800d8bd0c/lib-dyn/deps.ts:4:26
I've deleted my /Users/<me>/Library/Caches/deno/deps/https and reran the script a few times but I still can't get past this. In my browser trying to follow the URL https://dev.jspm.io/inherits#2.0 does give me an error. What is going on here? There's not much code and I imagine it's not broken for everybody. What do I need to do to get this script to run without issues?
EDIT: it seems to be a library error https://github.com/eveningkid/denodb/issues/348
This is an error caused by a nested depedency, from a project that is not maintained.
See this for more info: [https://jspm.org/jspm-dev-release]
The point is dev.jspm.io is now jspm.dev
A way to fix this is to fork and update depedencies.
Another thing, if you're not using deno deploy, you can just use this as a replacement for your denodb: https://raw.githubusercontent.com/joeldesante/denodb/master/mod.ts
Just note that this script is no more maintained either, but it will fix your problem
Edit
I just made a dirty quick fix for deno deploy use this as a depedency isntead of denodb: https://raw.githubusercontent.com/ninjinskii/denodb/master/mod.ts
Again, i may not maintain this script forever.
The best thing that can happen is an update from these libs maintainers
So I have the following in my package.json:
test-sl-one: "testcafe \"saucelabs:Chrome#beta:Windows 10\" tests/settings/users.js -r xunit:/tmp/test-results/res.xml"
I see the tunnel "active" on the saucelabs site.
I wait about four minutes, and then I get back the error:
testcafe-automated-tests#0.0.1 test-sl-one /home/circleci/repo
testcafe "saucelabs:Chrome#beta:Windows 10" tests/settings/users.js -r xunit:/tmp/test-results/res.xml
ERROR Unable to establish one or more of the specified browser connections. This can be caused by network issues or remote device failure.
Any advice on where to start to triage it etc would be greatly appreciated! :)
Details: I successfully run testcafe tests on circleci not using saucelabs (just using a docker image that has chrome/firefox in it).
Also, my tests are running inside a docker container (maybe I should stop doing this part)
I am doing the Pintos project on the side to learn more about operating systems. I had tons of devops trouble at first with it not running well on an 18.04 Ubuntu droplet. I am now running it on the VirtualBox image that UCCS tells students to download for pintos.
I finished project 1 and started to map out my solution to project 2. Following the instructions to create a file I ran
pintos-mkdisk filesys.dsk --filesys-size=2
pintos -- -f -q
but am getting error
Kernel PANIC at ../../threads/vaddr.h:87 in vtop(): assertion
`is_kernel_vaddr (vaddr)' failed.
I then tried running make check (all the tests). They are all failing for the same reason.
Am I missing something? Is there something I need to implement to fix this? I reread the instructions and didnt see anything?
Would appreciate help!
Thanks
I had a similar problem. My code for Project 1 ran fine, but I could not format the filesystem for Project 2.
The failure for me came from the following call chain:
thread_init() -> ... -> thread_schedule_tail() -> process_activate() -> pagedir_activate() -> vtop()
The problem is that init_page_dir is still NULL when pagedir_activate() is called. init_page_dir should have been initialized in paging_init() but this is called after thread_init().
The root cause was that my scheduler was being called too early, i.e. before the call to thread_start(). The reason for my problem was that I had built in a call to thread_yield() upon completion of every call to lock_release() which makes sense from a priority donation standpoint. Unfortunately, locks are used prior to the scheduler being ready! To fix this, I installed a flag called threading_started that bails in the first line of my thread_block() and thread_yield() functions if thread_start() has not yet been called.
Good luck!
I am using Nginx+Passenger.
I was trying to upgrade Phusion passenger from 5.0.29 to 5.1.11. Everything was fine except restarting of the passenger is throwing an error as shown in the image.
I tried to again run the chef-client, its restarted properly. But I have to run the chef-client twice which I cannot afford.
Until the completion of 2nd-time chef-client, my website is down.
Recipes details:
service "passenger" do
supports :status => true, :restart => true, :reload => true
action [ :enable, :start ]
end
Any Idea why it is happening.
Thanks
Try invoking /etc/init.d/passenger restart and see the result. In case you get the same error, the problem is that it does not support that operation.
Also, as a workaround try notifying to the resource stop start instead of restart, it will do the trick.
Finally, do you restart the service on each chef-client run? Is this really needed? It will imply a small downtime every ~30 minutes
For me, failed restarts (after a passenger upgrade) was related to this issue.
Try with downgrading passenger to 5.1.7 (or wait for the 5.1.12 release)
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.