-
Notifications
You must be signed in to change notification settings - Fork 317
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
local tests failing, but succeed in travis #504
Comments
Running
|
Hmm, that's odd. Thanks for reporting these. What version of linux are you running? For the first issue, there are some dirty hacks in place to get it to capture coverage data when running subprocesses, so it's possible that your system is configured in a way that is making that not work. I know you said you installed this on a clean VM, but just to be extra sure you have the most up-to-date versions of everything, can you try running For the second issue, that's a bizarre error. It's failling on:
Note that the second one (which is supposed to be an earlier date) is 15:7:23 while the first one is 13:7:24. I am not sure how it is possible that those dates are off by two hours. Can you rerun that test and let me know again:
I have heard that sometimes VMs have issues with the system clock running too fast or two slow. I don't know how that could cause issues with time going backwards, but maybe it's related? |
I'm running Ubuntu 14.04 For the first issue: For the second issue, i'm pretty sure this line: |
Ah, that could very well be. That would explain why it passes on Travis (though it wouldn't explain why it passes on my laptop). I'll investigate... |
Unless your system is set to the same time zone as UTC. |
Yeah, though my system isn't UTC. Anyway, I opened a PR to fix it (hopefully). For the first issue still... I'm not sure, but let's try a few things. First, can you run the following in a python terminal (from the nbgrader directory in the virtualenv you're using):
You should get something like
|
File location:
|
Just an idea here, but would it not be a good idea to leverage |
Ok, so that's fine. Hrm.
Possibly; I haven't used tox before. I am not sure this issue would be resolved by something like that, though, since the command that is run on travis is exactly The issue here is that when you run a subprocess, coverage doesn't (by default) capture what lines are being executed in the subprocess. So, you have to configure python to run coverage with the subprocess, which involves a combination of ensuring it starts up (in the For the time being, I am going to at least just turn that error into a warning, because it doesn't make sense for the tests themselves to fail if coverage doesn't work (though the coverage tests should still fail -- which they will, if coverage is not being captured). |
Yeah this issue is rather weird. Travis == Ubuntu, so I would expect running the same set of command as travis should give the same results :P From what I see, both methods Also AFAIK
I also tested this and got coverage data even with the test failing:
|
I would be happy to create a PR for this if you are interested. |
Yep, that's right.
Yeah, that's what it says, but when I was setting it up I found it didn't work 😞 What I have set up is described here: http://coverage.readthedocs.io/en/coverage-4.0.3/subprocess.html
You'll definitely get some coverage, just not all coverage. Not all the code runs in subprocesses, so whatever is not in a subprocess will still get covered. You can compare your coverage results with for example what Travis gets, which is slightly higher: https://travis-ci.org/jupyter/nbgrader/jobs/126909947
Well, the same commands are being run already ( |
This was run on a clean virtualenv on the master branch without any changes.
Am I doing something wrong?
The text was updated successfully, but these errors were encountered: