git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "SZEDER Gábor" <szeder.dev@gmail.com>
To: Lars Schneider <larsxschneider@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	Git mailing list <git@vger.kernel.org>
Subject: Re: [PATCH] travis-ci: build Git during the 'script' phase
Date: Fri, 12 Jan 2018 14:32:54 +0100	[thread overview]
Message-ID: <CAM0VKjnSzoc+E408ifKCg+qPTaGRNL3e3JVdRN573kdcBSzbHw@mail.gmail.com> (raw)
In-Reply-To: <5DE3FA05-2347-4BE7-8A1A-A6E5FEEC7C2B@gmail.com>

On Mon, Jan 8, 2018 at 11:38 PM, Lars Schneider
<larsxschneider@gmail.com> wrote:
>
>> On 08 Jan 2018, at 23:07, Junio C Hamano <gitster@pobox.com> wrote:
>>
>> SZEDER Gábor <szeder.dev@gmail.com> writes:
>>
>>> The reason why Travis CI does it this way and why it's a better
>>> approach than ours lies in how unsuccessful build jobs are
>>> categorized.  ...
>>> ...
>>> This makes it easier, both for humans looking at the Travis CI web
>>> interface and for automated tools querying the Travis CI API,...
>>> ...
>>> A verbose commit message for such a change... but I don't know why we
>>> started with building Git in the 'before_script' phase.
>>
>> Thanks for writing it up clearly.  TBH, I didn't even realize that
>> there were meaningful distinctions between the two cases after
>> seeing that sometimes our tests were failing and sometimes erroring
>> ;-)
>
> I understand the reasons for the proposed patch. However, I did this
> intentionally back then. Here is my reason:
>
> If `make` is successful, then I am not interested in its output.

If 'prove' is successful, then I'm not interested in its output ;)

> Look at this run: https://travis-ci.org/szeder/git/jobs/324271623
>
> You have to scroll down 1,406 lines to get to the test result
> output (this is usually the interesting part).

That's the just beginning of a looong list of executed test scripts in
seemingly pseudo-random order.  IMHO that's very rarely the interesting
part; I, for one, am only interested in that list in exceptional cases,
e.g. while tweaking the build dependencies or the 'prove --state=...'
options.

These are the really interesting parts of the build job's output, the
parts that do matter most of the time:

  # compiler error
  https://travis-ci.org/git/git/jobs/325252417#L1766
  # which tests failed
  https://travis-ci.org/git/git/jobs/315658238#L2247
  # stray build artifacts
  https://travis-ci.org/szeder/git/jobs/323531220#L2236
  # (no example logs for erroring while installing dependencies, OSX
  # timeout, etc.)

Note that these are all at the very end of the trace log, i.e. they are
easily accessible by one or two keystrokes (depending on whether the
keyboard has a dedicated 'End' key or requires an Fn combo), a vigorous
drag of the scrollbar, or a click on the "Scroll to end of log" circle
in the top right corner.

> If this is a valid argument for you,

I'm unconvinced :)

> would it be an option to
> pipe the verbose `make` output to a file and only print it in case
> of error (we do something similar for the tests already).

It's risky, because the build process would be completely silent for the
duration of building Git.  Travis CI considers a build 'errored' if it
doesn't produce any output for 10 minutes.  While building Git usually
takes much less time, transient slowdowns apparently do occur.

Gábor

  reply	other threads:[~2018-01-12 13:33 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-08 17:22 [PATCH] travis-ci: build Git during the 'script' phase SZEDER Gábor
2018-01-08 22:07 ` Junio C Hamano
2018-01-08 22:38   ` Lars Schneider
2018-01-12 13:32     ` SZEDER Gábor [this message]
2018-01-13 10:32       ` Jeff King
2018-01-13 10:54         ` Jeff King
2018-01-14 10:43           ` SZEDER Gábor
2018-01-14 11:10             ` Jeff King
2018-01-14 10:37         ` SZEDER Gábor
2018-01-14 11:07           ` Jeff King

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=CAM0VKjnSzoc+E408ifKCg+qPTaGRNL3e3JVdRN573kdcBSzbHw@mail.gmail.com \
    --to=szeder.dev@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=larsxschneider@gmail.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).