We aren't yet using these artifacts (we plan to build the production ones on
our buildbot machines), but this will make sure we don't break the process.
The OS-X builders don't offer a python environment, so we have to build
things ourselves (installing tox/etc with --user, instead of into the
virtualenv that "language: python" gives us).
Thanks to exarkun for the suggestion. The failing buildbots have LANG unset,
but I'm pretty sure that defaults to LANG=C, and LANG=C triggers the failures
just as well as LANG= did.
to catch things like ticket:2912
(https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2912)
Also clean up other "list"-ish keys to avoid causing too many builds:
* "os": move this into "matrix"
* "python": 2.7 is the default, and we weren't running the pypy build
anyways (not sure why, something else in this config must have disabled it,
maybe when we moved away from language: python)
* "allow_failures" was causing a pypy build to happen even without listing it
in "python"
We now have exactly three builds:
* linux
* linux with LANG=
* OS-X
The Travis OS-X worker has a very old setuptools-18.5 in /System. This is too
old to understand several important setup.py keys like `python_requires`, and
crashes when tryung to run the first invocation of tox (`tox -e codechecks`).
I think tox is using the system python (with which `tox` was invoked) to run
`setup.py egg_info` (to learn the dependencies), which gets the old
system-installed setuptools. Ideally it'd use the python from the
newly-created virtualenv, which would use whatever version of setuptools was
bundled with the `virtualenv` package (probably newer, given that
`virtualenv` itself should have been installed a moment earlier as a
dependency of `tox`.
I consider this a bug in Tox (https://github.com/tox-dev/tox/issues/507), but
the workaround is to configure Travis to install the most recent `setuptools`
along with `tox`.
refs tahoe-lafs/tahoe-lafs#470
travis apparently behaves like buildbot's ERROR_UPON_ERROR, rather that
HALT_UPON_ERROR, and if the tor install fails, then the integration test's
last step is certain to fail.
- (on travis) installs Tor
- installs Chutney
- uses it to build a local Tor test-network
- set up an introducer on this test-network
- sets up two storage servers on this test-network
- proves that one can add a file, and the other can download it
I also mark the two tests that occasionally fail as
expected failures for now
Travis defaults to giving us an OS-X 10.9 box, which has an OpenSSL that
is too old for the current cryptography-1.4 (note that a previous
version of this branch worked, but only because the previous
cryptography-1.3.x didn't enforce the OpenSSL version).
On OS-X, this new .travis.yml does the following:
* set "osx_image: xcode7" to get us 10.10, with newer OpenSSL
* uses system python, not homebrew
* installs pip with get-pip.py, since system python doesn't have it
* adds the --user directory to $PATH, since OS-X python doesn't have it
by default
On both linux and OS-X, this:
* installs tox and coveralls with --user, not to the system
* doesn't use sudo to run tox
* prints some extra debug info in case it's useful later
Closes#285
Twisted 15 dropped support for it, which causes Travis CI tests to fail on 2.6.
We still theoretically support older versions of Twisted, so perhaps we should
configure Travis to test with those? I think we should drop Python 2.6 in any
case since distros are all on 2.7 now.
I'm leaving Travis running (and ignoring) the failing PyPy tests because I
don't know why that is there.
Travis builds of branches (i.e. pull-requests) were testing the wrong
thing, because the 'git pull' was causing current trunk to be
auto-merged. At least that's what seemed to break
https://travis-ci.org/tahoe-lafs/tahoe-lafs/jobs/81517826 : it hung
forever waiting for a commit message to be entered.
Also add "sudo: false" to use travis containers (faster) instead of new
VMs. We only use pip to install dependencies, not apt, so we don't need
root.
This reverts commit cec7727bf9.
It caused travis (for py2.7) to fail on these tests:
* allmydata.test.test_runner.BinTahoe.test_version_no_noise
* allmydata.test.test_runner.RunNode.test_client_no_noise
* allmydata.test.test_system.SystemTest.test_filesystem_with_cli_in_subprocess
According to https://github.com/travis-ci/travis-ci/issues/2788 (which
was WONTFIXED), roughly half the travis-ci buildserver fleet runs off
tmpfs volumes, which have different notions of space-free and space-used
than real filesystems. We've adapted our tests to avoid relying upon
space-used>0, and no longer need this call to investigate the problem.
refs ticket:2290
