Hi Junio, On Wed, 22 Mar 2017, Junio C Hamano wrote: > Lars Schneider <larsxschneider@xxxxxxxxx> 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? Almost... Windows CI *cannot* subscribe to the GitHub repository, as only owners can install web hooks and give permission to update build status. But yeah, you understand correctly: this innocuous change (along with a ton of work I already finished on my side) allows us to let Travis trigger Windows build & test and to attach the log in the same place as the Linux/OSX results are already accessible. > > 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. > > For example, in https://travis-ci.org/git/git/jobs/213616973, which > is a log of the documentation build for #1335.6 ran for the 'master' > branch, you can see "ci/test-documentation.sh" string appearing in > the log twice. This comes from "script:" part, which is the same > mechanism this patch uses to invoke the new script with sekrit on > the command line. > > I am expecting that no expansion of "$GFW_CI_TOKEN" will be shown in > the output, but I've seen an incident where an unsuspecting 'set -x' > or '$cmd -v' revealed something that shouldn't have been made > public. I want to make sure we are sure that the command line this > patch adds does not get echoed with expansion to the log. Right, typically there is a way in CI setups that marks certain strings as secret and whenever they appear in the log, they will be blotted out. > Is GFW_CI_TOKEN known to be safe without double-quote around it, by > the way? Yes, it is safe without double-quotes. I generated it using: dd if=/dev/urandom bs=20 count=1 2> /dev/null | base64 > > 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. Yes, I think we have to use some kind of "skip" status if the build failed to run or finish in time. But I thought that the "timeout" status would fulfill that desire... Ciao, Dscho