threads / discuss / 48164

v2, 36 partsWindows build on Travis CI (was: Re: [PATCH v2 01/36] t/helper: add an empty test-tool program)

Subject: Windows build on Travis CI (was: Re: [PATCH v2 01/36] t/helper: add an empty test-tool program)

## tl;dr

2 messages between Mar 27, 2018 and Mar 27, 2018. Diffs are folded; open one to read it.

replies: 1people: 2as markdown or json

SZEDER Gábor· Mar 27, 2018, 15:02 UTC · lore

On Tue, Mar 27, 2018 at 3:57 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 26 quoted lines
> Hi Gábor,
>
> On Tue, 27 Mar 2018, SZEDER Gábor wrote:
>
>> On Tue, Mar 27, 2018 at 12:14 AM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>> > However, it seems that something is off, as
>> > ba5bec9589e9eefe2446044657963e25b7c8d88e is reported as fine on Windows:
>> > https://travis-ci.org/git/git/jobs/358260023 (while there is clearly a red
>> > X next to that commit in
>> > https://github.com/git/git/commits/ba5bec9589e9eefe2446044657963e25b7c8d88e,
>> > that X is due to a hiccup on macOS).
>> >
>> > It seems that the good-trees feature for Travis does not quite work as
>> > intended. Gábor?
>>
>> AFAICT it works as expected.
>>
>> When a build job encounters a commit with a tree that has previously
>> been built and tested successfully, then first it says so, like this:
>>
>>   https://travis-ci.org/szeder/git/jobs/347295038#L635
>
> But what if it has not been built successfully (as was the case here)?
> This very commit that is "succeeding" on Travis fails to compile on
> Windows.
Then why has the GfW web app reported success?
  https://travis-ci.org/git/git/jobs/358260023#L512
Show 14 quoted lines
>> and then skips the rest of the build job (see the 'exit 0' a few lines
>> later).
>>
>> In case of this Windows build job we haven't seen this tree yet:
>>
>>   https://travis-ci.org/git/git/jobs/358260023#L467
>>
>> so the build job continues as usual (see the 'test -z Windows' two lines
>> later).
>>
>> Unfortunately, I have no idea about how the rest of the Windows build
>> job is supposed to work...
>
> Maybe Travis timed out waiting for the result, and marked it as a success?

This Windows build ran for 9 min 27 sec, i.e. not long enough for a timeout on Travis CI. (OTOH, clearly not long enough to build Git and run the test suite on Windows, I know.)

BTW, a timeouted build job is marked as "errored" and the timeout is mentioned in its trace log:

  https://travis-ci.org/git/git/jobs/331669291#L509
Johannes Schindelin· Mar 27, 2018, 16:01 UTC · re: SZEDER Gábor · lore

Re: Windows build on Travis CI (was: Re: [PATCH v2 01/36] t/helper: add an empty test-tool program)

Hi Gábor,
On Tue, 27 Mar 2018, SZEDER Gábor wrote:
Show 31 quoted lines
> On Tue, Mar 27, 2018 at 3:57 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > On Tue, 27 Mar 2018, SZEDER Gábor wrote:
> >
> >> On Tue, Mar 27, 2018 at 12:14 AM, Johannes Schindelin
> >> <Johannes.Schindelin@gmx.de> wrote:
> >> > However, it seems that something is off, as
> >> > ba5bec9589e9eefe2446044657963e25b7c8d88e is reported as fine on Windows:
> >> > https://travis-ci.org/git/git/jobs/358260023 (while there is clearly a red
> >> > X next to that commit in
> >> > https://github.com/git/git/commits/ba5bec9589e9eefe2446044657963e25b7c8d88e,
> >> > that X is due to a hiccup on macOS).
> >> >
> >> > It seems that the good-trees feature for Travis does not quite work as
> >> > intended. Gábor?
> >>
> >> AFAICT it works as expected.
> >>
> >> When a build job encounters a commit with a tree that has previously
> >> been built and tested successfully, then first it says so, like this:
> >>
> >>   https://travis-ci.org/szeder/git/jobs/347295038#L635
> >
> > But what if it has not been built successfully (as was the case here)?
> > This very commit that is "succeeding" on Travis fails to compile on
> > Windows.
> 
> Then why has the GfW web app reported success?
> 
>   https://travis-ci.org/git/git/jobs/358260023#L512

Oy. There was a shift in build steps, so that shows the wrong output. The correct build step ends thusly:

-- snip -- [...] 2018-03-26T06:50:55.0000371Z Checking out files: 97% (3136/3232) 2018-03-26T06:50:55.0106984Z Checking out files: 98% (3168/3232) 2018-03-26T06:50:55.0223806Z Checking out files: 99% (3200/3232) 2018-03-26T06:50:55.0227819Z Checking out files: 100% (3232/3232) 2018-03-26T06:50:55.0228191Z Checking out files: 100% (3232/3232), done. 2018-03-26T06:50:55.0343621Z HEAD is now at 90bbd502d Sync with Git 2.16.3 2018-03-26T06:50:55.0759061Z Updating upstream 2018-03-26T06:50:56.3001946Z From https://github.com/git/git 2018-03-26T06:50:56.3002737Z * [new branch] maint -> upstream/maint 2018-03-26T06:50:56.3003056Z * [new branch] master -> upstream/master 2018-03-26T06:50:56.3003832Z * [new branch] next -> upstream/next 2018-03-26T06:50:56.3354328Z * [new branch] pu -> upstream/pu 2018-03-26T06:50:56.3354880Z * [new branch] todo -> upstream/todo 2018-03-26T06:50:56.8219992Z fatal: Not a valid commit name 7a6a7fb7d0ab1052db113318478f9e40e66e59dc 2018-03-26T06:50:56.8236547Z Commit 7a6a7fb7d0ab1052db113318478f9e40e66e59dc is not on branch upstream/master; skipping ```

So as you see, by the time we fetched `pu`, it was no longer reachable (otherwise we would have been able to fetch it).

That's a bummer.

Ciao, Dscho

← back to recent threads