On Mon, Jan 8, 2018 at 11:38 PM, Lars Schneider <larsxschneider@xxxxxxxxx> wrote: > >> On 08 Jan 2018, at 23:07, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> >> SZEDER Gábor <szeder.dev@xxxxxxxxx> 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
