# Windows build on Travis CI (was: Re: [PATCH v2 01/36] t/helper: add an empty test-tool program) 2 messages from 2018-03-27 to 2018-03-27. Participants: SZEDER Gábor, Johannes Schindelin. Thread: https://gitlist.dev/t/48164 ## SZEDER Gábor, 2018-03-27 15:02 Subject: Windows build on Travis CI (was: Re: [PATCH v2 01/36] t/helper: add an empty test-tool program) Message-ID: URL: https://gitlist.dev/e/CAM0VKjmRiOjb6Jsx1XCfGWe_9%2BAqJGeBvAWt2sM1_rJArdEVQA%40mail.gmail.com ``` On Tue, Mar 27, 2018 at 3:57 PM, Johannes Schindelin wrote: > Hi Gábor, > > On Tue, 27 Mar 2018, SZEDER Gábor wrote: > >> On Tue, Mar 27, 2018 at 12:14 AM, Johannes Schindelin >> 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 >> 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, 2018-03-27 16:01 Subject: Re: Windows build on Travis CI (was: Re: [PATCH v2 01/36] t/helper: add an empty test-tool program) Message-ID: URL: https://gitlist.dev/e/nycvar.QRO.7.76.6.1803271758490.77%40ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz In-Reply-To: ``` Hi Gábor, On Tue, 27 Mar 2018, SZEDER Gábor wrote: > On Tue, Mar 27, 2018 at 3:57 PM, Johannes Schindelin > wrote: > > > > On Tue, 27 Mar 2018, SZEDER Gábor wrote: > > > >> On Tue, Mar 27, 2018 at 12:14 AM, Johannes Schindelin > >> 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 ```