From: Jeff King <peff@peff.net>
To: larsxschneider@gmail.com
Cc: git@vger.kernel.org, luke@diamand.org, sunshine@sunshineco.com,
gitster@pobox.com
Subject: Re: [PATCH v6 6/6] Add Travis CI support
Date: Thu, 19 Nov 2015 09:35:29 -0500 [thread overview]
Message-ID: <20151119143528.GC9353@sigill.intra.peff.net> (raw)
In-Reply-To: <1447923491-15330-7-git-send-email-larsxschneider@gmail.com>
On Thu, Nov 19, 2015 at 09:58:11AM +0100, larsxschneider@gmail.com wrote:
> From: Lars Schneider <larsxschneider@gmail.com>
>
> The tests are currently executed on "Ubuntu 12.04 LTS Server Edition
> 64 bit" and on "OS X Mavericks" using gcc and clang.
>
> Perforce and Git-LFS are installed and therefore available for the
> respective tests.
My overall impression is that this is a lot more complicated than I was
expecting. Can we start with something simpler to gain experience with
Travis? And then we can add in more complexity later.
For example:
> +addons:
> + apt:
> + packages:
> + - language-pack-is
I doubt most people are running the t0204 right now. Maybe we should
start without it.
> +env:
> + global:
> + - P4_VERSION="15.1"
> + - GIT_LFS_VERSION="1.0.2"
I know p4 is your area of interest, but from a project perspective, it
seems like an odd choice for the initial set of tests.
> + - DEFAULT_TEST_TARGET=prove
> + - GIT_PROVE_OPTS="--timer --jobs 3"
> + - GIT_TEST_OPTS="--verbose --tee"
These all make sense, I guess.
> + - GETTEXT_ISO_LOCALE=YesPlease
> + - GETTEXT_LOCALE=YesPlease
What are these? I don't think we have any such Makefile knobs. These
look like variables that get used internally by the test suite, but we
shouldn't need to set them.
> + # - GETTEXT_POISON=YesPlease
I'm assuming the "#" means this is commented out. Can we just drop such
cruft?
> + - GIT_TEST_CHAIN_LINT=YesPlease
This is the default, and we don't need to specify it.
> + - GIT_TEST_CLONE_2GB=YesPlease
Is it a good idea to run such an expensive test?
> + matrix:
> + -
> + # NO_ICONV=YesPlease
Ditto here on the commenting.
> + - >
> + NO_CURL=YesPlease
So if I understand correctly, the point of this list is to test
alternate configurations. So compiling without curl makes some sense, I
guess. Though mostly it will just shut off a bunch off tests.
> + NO_D_INO_IN_DIRENT=YesPlease
But setting platform compat knobs like this seems weird. Nobody sets
this manually. Either your platform has it, or it does not. And we are
already testing on alternate platforms to cover such things.
If there's a specific config setup of interest, it makes sense to me to
try to increase test coverage there. But it feels like you've just
picked a random laundry list of Makefile knobs and tweaked them, without
any sense of whether they even make sense together, or match the
platform.
For instance:
> + NO_STRCASESTR=YesPlease
> + NO_STRLCPY=YesPlease
I wouldn't not be surprised if these cause problems building on some
platforms that _do_ have these functions.
> + echo "$(tput setaf 6)Perfoce Server Version$(tput sgr0)";
> + p4d -V | grep Rev.;
> + echo "$(tput setaf 6)Perfoce Client Version$(tput sgr0)";
> + p4 -V | grep Rev.;
s/Perfoce/Perforce/ :)
> +before_script: make configure && ./configure && make --jobs=2
Hmm. I wonder if we actually want to use autoconf here at all; most devs
do not use it, and Git should generally compile out of the box based on
config.mak.uname (and if it doesn't, it would be nice to know).
There may be some optional packages that autoconf helps with, though.
So overall, I dunno. I do not want to create a bunch of work for you in
splitting it up. But I'm hesitant to merge something that has a bunch of
lines that I'm not sure I understand the reasoning for. :-/
I was hoping the first cut could just be telling Travis to run "make
test", without much fanfare beyond that. Maybe that's not realistic.
-Peff
next prev parent reply other threads:[~2015-11-19 14:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-19 8:58 [PATCH v6 0/6] Add Travis CI support larsxschneider
2015-11-19 8:58 ` [PATCH v6 1/6] implement test_might_fail using a refactored test_must_fail larsxschneider
2015-11-19 8:58 ` [PATCH v6 2/6] add "ok=sigpipe" to test_must_fail and use it to fix flaky tests larsxschneider
2015-11-19 8:58 ` [PATCH v6 3/6] git-p4: retry kill/cleanup operations in tests with timeout larsxschneider
2015-11-19 8:58 ` [PATCH v6 4/6] git-p4: add p4d timeout in tests larsxschneider
2015-11-19 8:58 ` [PATCH v6 5/6] git-p4: add trap to kill p4d on test exit larsxschneider
2015-11-19 8:58 ` [PATCH v6 6/6] Add Travis CI support larsxschneider
2015-11-19 14:35 ` Jeff King [this message]
2015-11-20 9:29 ` Lars Schneider
2015-11-19 14:14 ` [PATCH v6 0/6] " Jeff King
2015-11-20 8:46 ` Lars Schneider
2015-11-20 12:56 ` Luke Diamand
2015-11-23 18:59 ` Jeff King
2015-11-23 21:19 ` Luke Diamand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151119143528.GC9353@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=larsxschneider@gmail.com \
--cc=luke@diamand.org \
--cc=sunshine@sunshineco.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).