On Sun, Jan 14, 2018 at 11:43:05AM +0100, SZEDER Gábor wrote:
> On Sat, Jan 13, 2018 at 11:54 AM, Jeff King wrote:
> > I think there's also a similar feature to include timings for each fold,
> > which might be worth pursuing.
>
> If you look for 'travis_time' in the raw log, you'll find lines l
On Sun, Jan 14, 2018 at 11:37:07AM +0100, SZEDER Gábor wrote:
> > +fold_cmd () {
> > + local name=$1; shift
> > + fold "$name"
> > + "$@"
> > + local ret=$?
> > + unfold "$name"
> > + return $ret
> > +}
>
> We don't have to fiddle with the return value, because
On Sat, Jan 13, 2018 at 11:54 AM, Jeff King wrote:
> I think there's also a similar feature to include timings for each fold,
> which might be worth pursuing.
If you look for 'travis_time' in the raw log, you'll find lines like
these:
travis_time:start:01ccbe40
$ some-command
... and its o
On Sat, Jan 13, 2018 at 11:32 AM, Jeff King wrote:
> On Fri, Jan 12, 2018 at 02:32:54PM +0100, SZEDER Gábor wrote:
>
>> 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 int
On Sat, Jan 13, 2018 at 05:32:56AM -0500, Jeff King wrote:
> According to:
>
> https://blog.travis-ci.com/2013-05-22-improving-build-visibility-log-folds
>
> they auto-fold individual commands _except_ the ones in the script
> section. Is there a way to manually mark folds in the output?
>
>
On Fri, Jan 12, 2018 at 02:32:54PM +0100, SZEDER Gábor wrote:
> 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 tw
On Mon, Jan 8, 2018 at 11:38 PM, Lars Schneider
wrote:
>
>> On 08 Jan 2018, at 23:07, Junio C Hamano wrote:
>>
>> SZEDER Gábor 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. ...
>>> .
> On 08 Jan 2018, at 23:07, Junio C Hamano wrote:
>
> SZEDER Gábor 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 Trav
SZEDER Gábor 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 Travi
Ever since we started building and testing Git on Travis CI (522354d70
(Add Travis CI support, 2015-11-27)), we build Git in the
'before_script' phase and run the test suite in the 'script' phase
(except in the later introduced 32 bit Linux and Windows build jobs,
where we build in the 'script' pha
10 matches
Mail list logo
