From: Lars Schneider <larsxschneider@gmail.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: git@vger.kernel.org, gitster@pobox.com
Subject: Re: [PATCH v1] Travis: also test on 32-bit Linux
Date: Thu, 2 Mar 2017 12:38:47 +0100 [thread overview]
Message-ID: <CFA1C4B4-0FDA-424D-87A4-EEE1F9BB3712@gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1703021210170.3767@virtualbox>
> On 02 Mar 2017, at 12:24, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> Hi Lars,
>
> On Thu, 2 Mar 2017, Lars Schneider wrote:
>
>> The patch looks good to me in general but I want to propose the following
>> changes:
>
> I know you are using your script to generate this mail, but I would have
> liked to see v2 in the subject ;-)
Yeah, sorry. I already had a "D'oh" moment *after* I saw the email in
my email client. Now I am wondering... is the next version v2 or v3 :D
>> (1) Move all the docker magic into a dedicated file
>> "ci/run-linux-32-build.sh" This way people should be able to run this
>> build on their local machines without TravisCI. However, I haven't
>> tested this.
>
> I considered this, but there is serious overlap: the `docker pull` call
> and the `docker run` call *have* to refer to the same image. It's very
> easy for them to get out of sync if you have that information in two
> files. Maybe make that an option of the script, defaulting to
> daald/ubuntu32:xenial?
Right. I missed that. How about something like that?
before_install:
- ci/run-linux32-build.sh --pull-container
before_script:
script: ci/run-linux32-build.sh
> BTW speaking of Docker: it would be nicer if there was a Docker image that
> already had the build-essentials installed, to save on startup time. But I
> did not find any that was reasonably up-to-date.
True. But installing everything just takes a minute and we don't need to
maintain anything...
>> +set -e
>
> Is this really necessary? I really like to avoid `set -e`, in particular
> when we do pretty much everything in && chains anyway.
Agreed, not really necessary here as we just invoke one command.
Out of curiosity: Why do you try to avoid it? I set it by default in all
my scripts.
>> +APT_INSTALL="apt update >/dev/null && apt install -y build-essential "\
>> +"libcurl4-openssl-dev libssl-dev libexpat-dev gettext python >/dev/null"
>> +
>> +TEST_GIT_ENV="DEFAULT_TEST_TARGET=$DEFAULT_TEST_TARGET "\
>> +"GIT_PROVE_OPTS=\"$GIT_PROVE_OPTS\" "\
>> +"GIT_TEST_OPTS=\"$GIT_TEST_OPTS\" "\
>> +"GIT_TEST_CLONE_2GB=$GIT_TEST_CLONE_2GB"
>> +
>> +TEST_GIT_CMD="linux32 --32bit i386 sh -c '"\
>> +"'$APT_INSTALL && cd /usr/src/git && $TEST_GIT_ENV make -j2 test'"
>> +
>> +sudo docker run \
>> + --interactive --volume "${PWD}:/usr/src/git" \
>> + daald/ubuntu32:xenial /bin/bash -c "$TEST_GIT_CMD"
>
> Hmm. Since it is a script now, it would be more readable this way, I
> think:
>
> sudo docker run --volume "${PWD}:/usr/src/git" "${1:-daald/ubuntu32:xenial}" \
> linux32 --32bit i386 sh -c '
> : update packages first &&
> apt update >/dev/null &&
> apt install -y build-essential libcurl4-openssl-dev libssl-dev \
> libexpat-dev gettext python >/dev/null &&
>
> : now build and test &&
> cd /usr/src/git &&
> DEFAULT_TEST_TARGET='"$DEFAULT_TEST_TARGET"' \
> GIT_PROVE_OPTS='"$GIT_PROVE_OPTS"' \
> GIT_TEST_OPTS='"$GIT_TEST_OPTS"' \
> GIT_TEST_CLONE_2GB='"$GIT_TEST_CLONE_2GB"' \
> make -j2 test
> '
That looks better! I'll try it!
- Lars
next prev parent reply other threads:[~2017-03-02 14:52 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-28 19:17 [PATCH] Travis: also test on 32-bit Linux Johannes Schindelin
2017-02-28 20:34 ` Johannes Schindelin
2017-03-02 5:06 ` Junio C Hamano
2017-03-02 10:51 ` [PATCH v1] " Lars Schneider
2017-03-02 11:24 ` Johannes Schindelin
2017-03-02 11:38 ` Lars Schneider [this message]
2017-03-02 14:22 ` Johannes Schindelin
2017-03-02 15:53 ` Christian Couder
2017-03-02 18:03 ` Junio C Hamano
2017-03-03 2:17 ` Johannes Schindelin
2017-03-03 18:43 ` Junio C Hamano
2017-03-04 0:03 ` Junio C Hamano
2017-03-04 4:11 ` Junio C Hamano
2017-03-04 17:23 ` Lars Schneider
2017-03-04 18:08 ` Vegard Nossum
2017-03-04 19:49 ` Vegard Nossum
2017-03-04 20:08 ` Vegard Nossum
2017-03-05 11:36 ` Jeff King
2017-03-05 11:44 ` [PATCH] line-log: use COPY_ARRAY to fix mis-sized memcpy Jeff King
2017-03-05 12:20 ` Vegard Nossum
2017-03-05 11:46 ` [PATCH v1] Travis: also test on 32-bit Linux Jeff King
2017-03-10 0:14 ` René Scharfe
2017-03-10 8:18 ` Jeff King
2017-03-10 16:20 ` René Scharfe
2017-03-10 17:57 ` Jeff King
2017-03-10 18:31 ` René Scharfe
2017-03-10 20:13 ` Junio C Hamano
2017-03-10 20:18 ` Jeff King
2017-03-10 22:04 ` René Scharfe
2017-03-10 23:33 ` Junio C Hamano
2017-03-11 14:17 ` René Scharfe
2017-03-10 0:14 ` René Scharfe
2017-03-10 7:45 ` Jeff King
2017-03-02 15:17 ` Ramsay Jones
2017-03-05 17:38 ` Lars Schneider
2017-03-05 22:16 ` Ramsay Jones
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CFA1C4B4-0FDA-424D-87A4-EEE1F9BB3712@gmail.com \
--to=larsxschneider@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).