- Aug 16, 2017
-
-
Max Dymond authored
closes #1747
-
- Aug 14, 2017
-
-
Daniel Stenberg authored
to make sure they keep building warning-free Closes #1777
-
- Aug 12, 2017
-
-
Daniel Stenberg authored
Could've prevented #1755
-
- Aug 10, 2017
-
-
Daniel Stenberg authored
Help-by: Jay Satiro Closes #1753
-
- Aug 04, 2017
-
-
Marcel Raad authored
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
-
- Aug 03, 2017
-
-
Daniel Stenberg authored
(to make the full line appear nicer on travis web UI)
-
Daniel Stenberg authored
Closes #1706
-
- Aug 02, 2017
-
-
Daniel Stenberg authored
-
Daniel Stenberg authored
-
- Jul 13, 2017
-
-
Max Dymond authored
Install libidn2 to increase test coverage (IDN tests) Closes https://github.com/curl/curl/pull/1673
-
- Jul 12, 2017
-
-
Marcel Raad authored
... to get warnings also on Linux/GCC and OSX/clang. Closes https://github.com/curl/curl/pull/1666
-
Max Dymond authored
Install libssh2 to increase test coverage (SFTP, SCP)
-
- Jul 07, 2017
-
-
Daniel Stenberg authored
-
Daniel Stenberg authored
Closes #1653
-
Daniel Stenberg authored
-
Daniel Stenberg authored
I added a selection of torture and event tests that run "fast enough"
-
- Jul 04, 2017
-
-
Daniel Stenberg authored
Closes #1642
-
Daniel Stenberg authored
... to better detect and fault on compiler warnings/errors Closes #1637
-
- Jun 21, 2017
-
-
Marcel Raad authored
- 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
-
Simon Warta authored
-
- Jun 20, 2017
-
-
Daniel Stenberg authored
-
- Jun 06, 2017
-
-
Daniel Stenberg authored
typecheck-gcc and other things require optimized builds Closes #1544
-
- Jun 03, 2017
-
-
Daniel Stenberg authored
Closes #1534
-
- Mar 22, 2017
-
-
Daniel Stenberg authored
-
- Aug 03, 2016
-
-
Sergei Nikulov authored
Fixes #943
-
- Aug 01, 2016
-
-
Sergei Nikulov authored
Apparently due to a broken homebrew install fixes #934 Closes #939
-
- Jul 28, 2016
-
-
Jay Satiro authored
Didn't work. This reverts commit 50723585.
-
Jay Satiro authored
CI is failing due to missing libtoolize, so I'm trying this.
-
- Aug 21, 2015
-
-
Jactry Zeng authored
-
- Aug 20, 2015
-
-
Rémy Léone authored
http://docs.travis-ci.com/user/migrating-from-legacy Closes #388
-
- Mar 10, 2015
-
-
Jay Satiro authored
- 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
-
- Oct 21, 2013
-
-
Rémy Léone authored
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).
-