| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
Seems that pretty much all aio tests fail on x64 musl builds.
|
|
|
|
|
|
|
|
* Gate Bors on the FreeBSD 11 build
* Remove the testless FreeBSD build from Travis
* Promote x86_64-unknown-freebsd to Tier 1
Fixes #603
|
|
@homu has served us well, but is unmaintained. bors will serve us in
its stead.
Fixes https://github.com/nix-rust/nix/issues/580
|
|
|
|
|
|
Fixes https://github.com/nix-rust/nix/issues/529, also refer to
https://github.com/nix-rust/nix/issues/529 which first added this
for the old CI infrastructure.
Signed-off-by: Paul Osborne <osbpau@gmail.com>
|
|
|
|
Removed:
- mips64-unknown-linux-gnu
- mips64el-unknown-linux-gnu
- arm-unknown-linux-musleabi
|
|
Added:
- arm-unknown-linux-gnueabi
- arm-unknown-linux-musleabi
Removed:
- powerpc64-unknown-linux-gnu (not suppported by nix)
- mips64el-unknown-linux-gnu (not suppported by nix)
- mipsel-unknown-linux-gnu (not suppported by nix)
|
|
|
|
|
|
|
|
|
|
Libraries we depend on need newer versions of Rust. The current
stable release is 1.13.
This also disables the CI for the platforms/architectures MIPS, ARM
and Android. This cannot be helped as long as the test infrastructure
only runs on 1.7.
|
|
Fixes #435
|
|
Supporting older verisons of rust is causing CI to fail and is
a somewhat constant support burden with questionable value. 1.7.0
is the oldest I have seen that people have had a requirement on
supporting in recent history.
It may make sense to work toward a more official policy on
what version of rust we will support in the future. Users of
older version of rust are, of course, welcome to use older versions
of nix and everything else in the ecosystem.
Signed-off-by: Paul Osborne <osbpau@gmail.com>
|
|
|
|
|
|
Signed-off-by: Paul Osborne <osbpau@gmail.com>
|
|
This moves things around a fair bit in the .travis.yml to be
more logically ordered and adds support for publishing docs
(on master) to gh-pages. Code coverage is also calculated
and published to coveralls.io.
Travis is able to write to gh-pages on the github repository
via the GH_TOKEN environment variable stored in the travis
settings (marked as private). This token is generated from
the github user 'rust-nix-bot' in order to avoid given access
to other repos associated with an actual user's account (this
practice is recommended by Github).
Other changes worth noting:
- We now test fewer intermediate versions of rust
- The existing logic to publish to Carl's S3 bucket have been removed.
Signed-off-by: Paul Osborne <osbpau@gmail.com>
|
|
|
|
|
|
Signed-off-by: Paul Osborne <osbpau@gmail.com>
|
|
We are using containers for a majority of builds again, so perform
those builds on more platforms (as travis seems to handle this much
better).
For OSX, we now testing i686/x86_64 on 1.1.0 as well for added
coverage.
Signed-off-by: Paul Osborne <osbpau@gmail.com>
|
|
Signed-off-by: Paul Osborne <osbpau@gmail.com>
|
|
All of the platforms tested currently fail in some way currently, but
the infrastructure itself appears to be working. As we have moved to
the legacy infrastructure (required in order to use docker), the tests
do run slower now. To compensate for that, i686 builds are only done on
stable and we do not test every version between the current stable and
the oldest version we support.
Signed-off-by: Paul Osborne <osbpau@gmail.com>
|
|
This is based on libc and the new docker-based testing infrastructure
via posborne/rust-cross.
Signed-off-by: Paul Osborne <osbpau@gmail.com>
|
|
Currently, several of the tests are failing intermittently. After
some research it appears that these failures only occur when thread
parallelism is enabled (as is the case by default). To test, I just
ran the failing tests over and over. I would consistently see errors
when running the following:
$ while true; do target/debug/test-7ec4d9681e812f6a; done
When I forced single threaded execution, I no longer saw failures:
$ while true; do RUST_TEST_THREADS=1 target/debug/test-7ec4d9681e812f6a; done
I was mostly looking at the test_unistd failures which make calls out
to fork() and then make subsequent calls to wait(). In that case there
is one parent and the wait() called could (and frequently does) get some
random child pid back because it just happened to terminate. That is
why when one of the test fails so does the other one.
I couldn't think of an obvious fix other than preventing thread
parallelism in the short term. The tests still run very quickly.
https://github.com/nix-rust/nix/issues/251
Signed-off-by: Paul Osborne <osbpau@gmail.com>
|
|
refs https://github.com/carllerche/nix-rust/issues/252
|
|
They appear to be having intermittent build failures. Two builds at the
same commit with different failures:
- https://travis-ci.org/kamalmarhubi/nix-rust/builds/105335248
- https://travis-ci.org/kamalmarhubi/nix-rust/builds/105336327
refs https://github.com/carllerche/nix-rust/issues/252
|
|
refs https://github.com/carllerche/nix-rust/issues/238
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
