Age | Commit message (Collapse) | Author |
|
Signed-off-by: Nikos Mavrogiannopoulos <nmav@redhat.com>
|
|
Uses a separate build without --enable-debug and no valgrind.
The debug option causes far too many warnings in boringssl's headers
(C++ comments, trailing commas etc). Valgrind triggers some false
positive errors in thread-local data used by boringssl.
Closes #2118
|
|
|
|
We don't expect any steps to fail in travis. Exit the script if they do.
Closes #1966
|
|
Use the external curl-fuzzer repository for fuzzing.
Closes #1923
|
|
- openssl is already installed and causes warnings when trying to
install again
- libidn isn't used these days, and homebrew doesn't seem to have a
libidn2 package to replace with easily
Closes #1895
|
|
Closes https://github.com/curl/curl/pull/1687
|
|
|
|
Closes #1868
|
|
Automake gets confused if you want to use C++ static libraries with C
code - basically we need to involve the clang++ linker. The easiest way
of achieving this is to rename the C code as C++ code. This gets us a
bit further along the path and ought to be compatible with Google's
version of clang.
|
|
- Start with the basic code from the ossfuzz project.
- Rewrite fuzz corpora to be binary files full of Type-Length-Value
data, and write a glue layer in the fuzzing function to convert
corpora into CURL options.
- Have supporting functions to generate corpora from existing tests
- Integrate with Makefile.am
|
|
Closes #1790
|
|
closes #1747
|
|
to make sure they keep building warning-free
Closes #1777
|
|
Could've prevented #1755
|
|
Help-by: Jay Satiro
Closes #1753
|
|
This makes the builds more reproducible as travis is currently rolling
out trusty as default dist [1]. Specifically, this avoids coverage
check failures when trusty is used as seen in [2] until we figure out
what's wrong.
[1] https://blog.travis-ci.com/2017-07-11-trusty-as-default-linux-is-coming
[2] https://github.com/curl/curl/pull/1692
Closes https://github.com/curl/curl/pull/1725
|
|
(to make the full line appear nicer on travis web UI)
|
|
Closes #1706
|
|
|
|
|
|
Install libidn2 to increase test coverage (IDN tests)
Closes https://github.com/curl/curl/pull/1673
|
|
... to get warnings also on Linux/GCC and OSX/clang.
Closes https://github.com/curl/curl/pull/1666
|
|
Install libssh2 to increase test coverage (SFTP, SCP)
|
|
|
|
Closes #1653
|
|
|
|
I added a selection of torture and event tests that run "fast enough"
|
|
Closes #1642
|
|
... to better detect and fault on compiler warnings/errors
Closes #1637
|
|
- switch debug and release configurations so that we get an optimized
build with GCC 4.3+ as required by typecheck-gcc
- enable warnings-as-errors for release builds
(which have warnings disabled)
Closes https://github.com/curl/curl/pull/1595
|
|
|
|
|
|
typecheck-gcc and other things require optimized builds
Closes #1544
|
|
Closes #1534
|
|
|
|
Fixes #943
|
|
Apparently due to a broken homebrew install
fixes #934
Closes #939
|
|
Didn't work.
This reverts commit 50723585ed380744358de054e2a55dccee65dfd7.
|
|
CI is failing due to missing libtoolize, so I'm trying this.
|
|
|
|
http://docs.travis-ci.com/user/migrating-from-legacy
Closes #388
|
|
- Change the continuous integration script to use 'make test-full'
instead of just 'make test' so that the diagnostic log output is
printed to stdout when a test fails.
- Change the continuous integration script to use
'./configure --enable-debug' instead of just './configure' so that the
memory analyzer will work during testing.
Prior to this change Travis used its default C test script:
./configure && make && make test
|
|
From wikipedia:
Travis CI is a hosted, distributed continuous integration service used
to build and test projects hosted at GitHub.
Travis CI is configured by adding a file named .travis.yml, which is a
YAML format text file, to the root directory of the GitHub repository.
Travis CI automatically detects when a commit has been made and pushed
to a GitHub repository that is using Travis CI, and each time this
happens, it will try to build the project and run tests. This includes
commits to all branches, not just to the master branch. When that
process has completed, it will notify a developer in the way it has been
configured to do so — for example, by sending an email containing the
test results (showing success or failure), or by posting a message on an
IRC channel. It can be configured to run the tests on a range of
different machines, with different software installed (such as older
versions of a programming language, to test for compatibility).
|