Closed danielparton closed 9 years ago
True, thanks :)
Which packages are we still relying on the dannyparton
binstar repo for?
conda config --add channels https://conda.anaconda.org/dannyparton
TargetExplorer requires the flask-sqlalchemy extension - I added a recipe on choderalab/conda-recipes, but that won't be available until Jenkins etc is set up.
In the mean time, I was going to upload binaries on my own binstar channel. I can remove that channel from install.sh
once flask-sqlalchemy is available via the choderalab channel.
OK, I almost have Jenkins working for choderalab. Will let you know when it works.
So the flask-sqlalchemy dependency is installing fine now it is available on the choderalab conda channel. Unfortunately Oncotator seems to be down at the moment (see screen grab below), causing a couple of the tests to fail with the following exception.
HTTPError: HTTP Error 503: Service Temporarily Unavailable
It's inevitable that tests which rely on external resources will result in this kind of difficulty. But I think it should be fairly easy to implement exception handling in the tests to deal with this specific situation.
Example code for handling this:
from urllib2 import HTTPError
from nose import SkipTest
def test_gather_cbioportal():
with projecttest_context(set_up_project_stage='uniprot'):
try:
GatherCbioportalData()
except HTTPError as e:
if e.code == 503:
raise SkipTest(e.reason)
else:
raise
And this is the description of the 503 HTTP code from w3.org:
10.5.4 503 Service Unavailable
The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the client SHOULD handle the response as it would for a 500 response.
Note: The existence of the 503 status code does not imply that a server must use it when becoming overloaded. Some servers may wish to simply refuse the connection.
Will need to think whether we actually want to skip tests in this situation.
Might be better to just consider any test with external dependencies to be an "integration test" rather than a unit test, and avoid making CI dependent upon them. Such tests could be labeled with an "integration" attribute decorator. And these could perhaps be run at the end of the after_success.sh
script, just to provide the developer with that info, but without making Travis (and dev
builds) dependent upon them passing.
I don't think you want your
secure
line to be commented out: