> On 22 Mar 2017, at 20:29, Junio C Hamano <gits...@pobox.com> wrote:
> 
> Lars Schneider <larsxschnei...@gmail.com> writes:
> 
>> Therefore, we did the following:
>> * Johannes Schindelin set up a Visual Studio Team Services build
>>  sponsored by Microsoft and made it accessible via an Azure Function
>>  that speaks a super-simple API. We made TravisCI use this API to
>>  trigger a build, wait until its completion, and print the build and
>>  test results.
>> * A Windows build and test run takes up to 3h and TravisCI has a timeout
>>  after 50min for Open Source projects. Since the TravisCI job does not
>>  use heavy CPU/memory/etc. resources, the friendly TravisCI folks
>>  extended the job timeout for git/git to 3h.
> 
> The benefit is that Windows CI does not have to subscribe to the
> GitHub repository to get notified (instead uses Travis as a relay
> for update notification) and the result can be seen at the same
> place as results on other platforms Travis natively support are
> shown?  
Correct!

> Very nice.

Thanks :-)


>> Things, that would need to be done:
>> * Someone with write access to https://travis-ci.org/git/git would need
>>  to add the secret token as "GFW_CI_TOKEN" variable in the TravisCI
>>  repository setting [1]. Afterwards the build should just work.
> 
> We need to make sure this does not leak to the execution log of
> Travis.

True. I think I took care of this and it should not leak!


>> Things, that might need to be done:
>> * The Windows box can only process a single build at a time. A second
>>  Windows build would need to wait until the first finishes.
> 
> Perhaps instead of accumulating pending requests, perhaps we can
> arrange so that Travis skips a build/test request that is not even
> started yet for the same branch?  For branches that are never
> rewound, a breakage in an earlier pushout would either show in a
> later pushout of the same branch (if breakage is not fixed yet), or
> doesn't (if the later pushout was to fix that breakage), and in
> either case, it is not useful to test the earlier pushout when a
> newer one is already available for testing.  For branches that are
> constantly rewound, again, it is not useful to test the earlier
> pushout when a newer one is already available for testing.

Well, look at this. TravisCi *just* released a solution to
exactly that problem! Good timing!
https://blog.travis-ci.com/2017-03-22-introducing-auto-cancellation


>> diff --git a/ci/run-windows-build.sh b/ci/run-windows-build.sh
>> new file mode 100755
>> index 0000000000..324a9ea4e6
>> --- /dev/null
>> +++ b/ci/run-windows-build.sh
>> @@ -0,0 +1,55 @@
>> +#!/usr/bin/env bash
> 
> I know this is not a usual scripted Porcelain that must be usable by
> all users, but I do not see anything that requires bash-ism in the
> script.  Can we just do "#!/bin/sh", avoid bash-isms, and follow the
> usual coding guidelines in general?

Sure!


>> +[ $# -eq 3 ] || (echo "Unexpected number of parameters" && exit 1)
> 
> i.e.e.g "test $# = 3" || ...
> 
>> +# Check if the $BUILD_ID contains a number
>> +case $BUILD_ID in
>> +    ''|*[!0-9]*) echo $BUILD_ID && exit 1
>> +esac
> 
> Too deep an indent of a case arm, i.e. align them with case/esac, like
> 
>        case $BUILD_ID in
>        ''|*[!0-9]*) echo $BUILD_ID && exit 1
>        esac

Will do in v2!


Thanks,
Lars

Reply via email to