{"thread":{"id":"45462","subject":"[PATCH v1] travis-ci: build and test Git on Windows","startedAt":"2017-03-22T06:57:35Z","lastAt":"2017-03-24T23:50:17Z","messageCount":24,"participants":["Lars Schneider","Johannes Schindelin","Junio C Hamano","Jeff King","Samuel Lijin"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"314893","messageId":"20170322065612.18797-1-larsxschneider@gmail.com","threadId":"45462","inReplyTo":null,"subject":"[PATCH v1] travis-ci: build and test Git on Windows","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2017-03-22T06:56:12Z","receivedAt":"2017-03-22T06:57:35Z","isPatch":true,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"Most Git developers work on Linux and they have no way to know if their\nchanges would break the Git for Windows build. Let's fix that by adding\na job to TravisCI that builds and tests Git on Windows. Unfortunately,\nTravisCI does not support Windows.\n\nTherefore, we did the following:\n* Johannes Schindelin set up a Visual Studio Team Services build\n  sponsored by Microsoft and made it accessible via an Azure Function\n  that speaks a super-simple API. We made TravisCI use this API to\n  trigger a build, wait until its completion, and print the build and\n  test results.\n* A Windows build and test run takes up to 3h and TravisCI has a timeout\n  after 50min for Open Source projects. Since the TravisCI job does not\n  use heavy CPU/memory/etc. resources, the friendly TravisCI folks\n  extended the job timeout for git/git to 3h.\n\nThings, that would need to be done:\n* Someone with write access to https://travis-ci.org/git/git would need\n  to add the secret token as \"GFW_CI_TOKEN\" variable in the TravisCI\n  repository setting [1]. Afterwards the build should just work.\n\nThings, that might need to be done:\n* The Windows box can only process a single build at a time. A second\n  Windows build would need to wait until the first finishes. This\n  waiting time and the build time after the wait could exceed the 3h\n  threshold. If this is a problem, then it is likely to happen every day\n  as usually multiple branches are pushed at the same time (pu/next/\n  master/maint). I cannot test this as my TravisCI account has the 50min\n  timeout. One solution could be to limit the number of concurrent\n  TravisCI jobs [2].\n\n[1] https://docs.travis-ci.com/user/environment-variables#Defining-Variables-in-Repository-Settings\n[2] https://docs.travis-ci.com/user/customizing-the-build#Limiting-Concurrent-Builds\n\nSigned-off-by: Lars Schneider <larsxschneider@gmail.com>\n---\n\nNotes:\n    Base Ref: master\n    Web-Diff: https://github.com/larsxschneider/git/commit/322094c0a2\n    Checkout: git fetch https://github.com/larsxschneider/git travisci/win-v1 && git checkout 322094c0a2\n\n .travis.yml             | 11 ++++++++++\n ci/run-windows-build.sh | 55 +++++++++++++++++++++++++++++++++++++++++++++++++\n 2 files changed, 66 insertions(+)\n create mode 100755 ci/run-windows-build.sh\n\ndiff --git a/.travis.yml b/.travis.yml\nindex 591cc57b80..a7e98ae519 100644\n--- a/.travis.yml\n+++ b/.travis.yml\n@@ -39,6 +39,17 @@ env:\n \n matrix:\n   include:\n+    - env: Windows\n+      os: linux\n+      compiler:\n+      addons:\n+      before_install:\n+      before_script:\n+      script:\n+        - >\n+          test \"$TRAVIS_REPO_SLUG\" != \"git/git\" ||\n+          ci/run-windows-build.sh $GFW_CI_TOKEN $TRAVIS_BRANCH $(git rev-parse HEAD)\n+      after_failure:\n     - env: Linux32\n       os: linux\n       services:\ndiff --git a/ci/run-windows-build.sh b/ci/run-windows-build.sh\nnew file mode 100755\nindex 0000000000..324a9ea4e6\n--- /dev/null\n+++ b/ci/run-windows-build.sh\n@@ -0,0 +1,55 @@\n+#!/usr/bin/env bash\n+#\n+# Script to trigger the a Git for Windows build and test run.\n+# Pass a token, the branch (only branches on https://github.com/git/git)\n+# are supported), and a commit hash.\n+#\n+\n+[ $# -eq 3 ] || (echo \"Unexpected number of parameters\" && exit 1)\n+\n+TOKEN=$1\n+BRANCH=$2\n+COMMIT=$3\n+\n+gfwci () {\n+\tcurl \\\n+\t\t-H \"Authentication: Bearer $TOKEN\" \\\n+\t\t--silent --retry 5 \\\n+\t\t\"https://git-for-windows-ci.azurewebsites.net/api/TestNow?$1\" |\n+\tsed \"$(printf '1s/^\\xef\\xbb\\xbf//')\"  # Remove the Byte Order Mark\n+}\n+\n+# Trigger build job\n+BUILD_ID=$(gfwci \"action=trigger&branch=$BRANCH&commit=$COMMIT&skipTests=false\")\n+\n+# Check if the $BUILD_ID contains a number\n+case $BUILD_ID in\n+\t''|*[!0-9]*) echo $BUILD_ID && exit 1\n+esac\n+\n+echo \"Visual Studio Team Services Build #${BUILD_ID}\"\n+\n+# Wait until build job finished\n+STATUS=\n+RESULT=\n+while true\n+do\n+\tLAST_STATUS=$STATUS\n+\tSTATUS=$(gfwci \"action=status&buildId=$BUILD_ID\")\n+\t[ \"$STATUS\" == \"$LAST_STATUS\" ] || printf \"\\nStatus: $STATUS \"\n+\tprintf \".\"\n+\n+\tcase $STATUS in\n+\t\tinProgress|postponed|notStarted) sleep 10                      ;; # continue\n+\t\t         \"completed: succeeded\") RESULT=\"success\";        break;; # success\n+\t\t                              *) echo \"Unknown: $STATUS\"; break;; # failure\n+\tesac\n+done\n+\n+# Print log\n+echo \"\"\n+echo \"\"\n+gfwci \"action=log&buildId=$BUILD_ID\" | cut -c 30-\n+\n+# Set exit code for TravisCI\n+[ \"$RESULT\" == \"success\" ]\n\nbase-commit: afd6726309f57f532b4b989a75c1392359c611cc\n-- \n2.11.1\n\n"},{"id":"314910","messageId":"alpine.DEB.2.20.1703221641070.3767@virtualbox","threadId":"45462","inReplyTo":"20170322065612.18797-1-larsxschneider@gmail.com","subject":"Re: [PATCH v1] travis-ci: build and test Git on Windows","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-03-22T15:49:28Z","receivedAt":"2017-03-22T15:51:49Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Lars,\n\nOn Wed, 22 Mar 2017, Lars Schneider wrote:\n\n> Things, that might need to be done:\n> * The Windows box can only process a single build at a time. A second\n>   Windows build would need to wait until the first finishes. This\n>   waiting time and the build time after the wait could exceed the 3h\n>   threshold. If this is a problem, then it is likely to happen every day\n>   as usually multiple branches are pushed at the same time (pu/next/\n>   master/maint). I cannot test this as my TravisCI account has the 50min\n>   timeout. One solution could be to limit the number of concurrent\n>   TravisCI jobs [2].\n\nThere is another possibility, too, of course: I may be able to find more\nresources and add other VMs which could be used to build and run the\ntests.\n\nOf course, if those tests would not spawn billions of POSIX processes,\nthings would be faster, too, and we could afford to wait for a single\nbuild agent.\n\n> diff --git a/ci/run-windows-build.sh b/ci/run-windows-build.sh\n> new file mode 100755\n> index 0000000000..324a9ea4e6\n> --- /dev/null\n> +++ b/ci/run-windows-build.sh\n> @@ -0,0 +1,55 @@\n> +#!/usr/bin/env bash\n> +#\n> +# Script to trigger the a Git for Windows build and test run.\n> +# Pass a token, the branch (only branches on https://github.com/git/git)\n> +# are supported), and a commit hash.\n> +#\n> +\n> +[ $# -eq 3 ] || (echo \"Unexpected number of parameters\" && exit 1)\n> +\n> +TOKEN=$1\n> +BRANCH=$2\n> +COMMIT=$3\n> +\n> +gfwci () {\n> +\tcurl \\\n> +\t\t-H \"Authentication: Bearer $TOKEN\" \\\n> +\t\t--silent --retry 5 \\\n> +\t\t\"https://git-for-windows-ci.azurewebsites.net/api/TestNow?$1\" |\n> +\tsed \"$(printf '1s/^\\xef\\xbb\\xbf//')\"  # Remove the Byte Order Mark\n> +}\n> +\n> +# Trigger build job\n> +BUILD_ID=$(gfwci \"action=trigger&branch=$BRANCH&commit=$COMMIT&skipTests=false\")\n> +\n> +# Check if the $BUILD_ID contains a number\n> +case $BUILD_ID in\n> +\t''|*[!0-9]*) echo $BUILD_ID && exit 1\n\nError messages are delivered that way, and they do not start with digits,\ntrue. But maybe there is an exit status to indicate to Travis that we\ncannot decide whether the build failed or succeeded in that case? The most\ncommon cause for an error here is that the VM I use for testing is down\n(which happens every once in a while to save on resources, and I have to\nmanually restart it)...\n\n> +echo \"Visual Studio Team Services Build #${BUILD_ID}\"\n\nNice plug, thanks! ;-)\n\n> +# Wait until build job finished\n> +STATUS=\n> +RESULT=\n> +while true\n> +do\n> +\tLAST_STATUS=$STATUS\n> +\tSTATUS=$(gfwci \"action=status&buildId=$BUILD_ID\")\n> +\t[ \"$STATUS\" == \"$LAST_STATUS\" ] || printf \"\\nStatus: $STATUS \"\n> +\tprintf \".\"\n> +\n> +\tcase $STATUS in\n> +\t\tinProgress|postponed|notStarted) sleep 10                      ;; # continue\n> +\t\t         \"completed: succeeded\") RESULT=\"success\";        break;; # success\n> +\t\t                              *) echo \"Unknown: $STATUS\"; break;; # failure\n\nWell, there are more values for the status, and we know them, but we do\nnot handle them. Maybe \"Unhandled status:\"?\n\n> +\tesac\n> +done\n> +\n> +# Print log\n> +echo \"\"\n> +echo \"\"\n> +gfwci \"action=log&buildId=$BUILD_ID\" | cut -c 30-\n> +\n> +# Set exit code for TravisCI\n> +[ \"$RESULT\" == \"success\" ]\n\nVery nice. Thank you so much for keeping me working on this!\n\nCiao,\nDscho\n"},{"id":"314947","messageId":"xmqqwpbhjej6.fsf@gitster.mtv.corp.google.com","threadId":"45462","inReplyTo":"20170322065612.18797-1-larsxschneider@gmail.com","subject":"Re: [PATCH v1] travis-ci: build and test Git on Windows","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-03-22T19:29:49Z","receivedAt":"2017-03-22T19:30:19Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Lars Schneider <larsxschneider@gmail.com> writes:\n\n> Therefore, we did the following:\n> * Johannes Schindelin set up a Visual Studio Team Services build\n>   sponsored by Microsoft and made it accessible via an Azure Function\n>   that speaks a super-simple API. We made TravisCI use this API to\n>   trigger a build, wait until its completion, and print the build and\n>   test results.\n> * A Windows build and test run takes up to 3h and TravisCI has a timeout\n>   after 50min for Open Source projects. Since the TravisCI job does not\n>   use heavy CPU/memory/etc. resources, the friendly TravisCI folks\n>   extended the job timeout for git/git to 3h.\n\nThe benefit is that Windows CI does not have to subscribe to the\nGitHub repository to get notified (instead uses Travis as a relay\nfor update notification) and the result can be seen at the same\nplace as results on other platforms Travis natively support are\nshown?  \n\nVery nice.\n\n> Things, that would need to be done:\n> * Someone with write access to https://travis-ci.org/git/git would need\n>   to add the secret token as \"GFW_CI_TOKEN\" variable in the TravisCI\n>   repository setting [1]. Afterwards the build should just work.\n\nWe need to make sure this does not leak to the execution log of\nTravis.\n\nFor example, in https://travis-ci.org/git/git/jobs/213616973, which\nis a log of the documentation build for #1335.6 ran for the 'master'\nbranch, you can see \"ci/test-documentation.sh\" string appearing in\nthe log twice.  This comes from \"script:\" part, which is the same\nmechanism this patch uses to invoke the new script with sekrit on\nthe command line.\n\nI am expecting that no expansion of \"$GFW_CI_TOKEN\" will be shown in\nthe output, but I've seen an incident where an unsuspecting 'set -x'\nor '$cmd -v' revealed something that shouldn't have been made\npublic.  I want to make sure we are sure that the command line this\npatch adds does not get echoed with expansion to the log.\n\nIs GFW_CI_TOKEN known to be safe without double-quote around it, by\nthe way?\n\n> Things, that might need to be done:\n> * The Windows box can only process a single build at a time. A second\n>   Windows build would need to wait until the first finishes.\n\nPerhaps instead of accumulating pending requests, perhaps we can\narrange so that Travis skips a build/test request that is not even\nstarted yet for the same branch?  For branches that are never\nrewound, a breakage in an earlier pushout would either show in a\nlater pushout of the same branch (if breakage is not fixed yet), or\ndoesn't (if the later pushout was to fix that breakage), and in\neither case, it is not useful to test the earlier pushout when a\nnewer one is already available for testing.  For branches that are\nconstantly rewound, again, it is not useful to test the earlier\npushout when a newer one is already available for testing.\n\n> diff --git a/ci/run-windows-build.sh b/ci/run-windows-build.sh\n> new file mode 100755\n> index 0000000000..324a9ea4e6\n> --- /dev/null\n> +++ b/ci/run-windows-build.sh\n> @@ -0,0 +1,55 @@\n> +#!/usr/bin/env bash\n\nI know this is not a usual scripted Porcelain that must be usable by\nall users, but I do not see anything that requires bash-ism in the\nscript.  Can we just do \"#!/bin/sh\", avoid bash-isms, and follow the\nusual coding guidelines in general?\n\n> +[ $# -eq 3 ] || (echo \"Unexpected number of parameters\" && exit 1)\n\ni.e.e.g \"test $# = 3\" || ...\n\n> +# Check if the $BUILD_ID contains a number\n> +case $BUILD_ID in\n> +\t''|*[!0-9]*) echo $BUILD_ID && exit 1\n> +esac\n\nToo deep an indent of a case arm, i.e. align them with case/esac, like\n\n        case $BUILD_ID in\n        ''|*[!0-9]*) echo $BUILD_ID && exit 1\n        esac\n\nThanks.\n"},{"id":"315110","messageId":"alpine.DEB.2.20.1703231716320.3767@virtualbox","threadId":"45462","inReplyTo":"xmqqwpbhjej6.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v1] travis-ci: build and test Git on Windows","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-03-23T16:22:51Z","receivedAt":"2017-03-23T16:23:25Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Wed, 22 Mar 2017, Junio C Hamano wrote:\n\n> Lars Schneider <larsxschneider@gmail.com> writes:\n> \n> > Therefore, we did the following:\n> > * Johannes Schindelin set up a Visual Studio Team Services build\n> >   sponsored by Microsoft and made it accessible via an Azure Function\n> >   that speaks a super-simple API. We made TravisCI use this API to\n> >   trigger a build, wait until its completion, and print the build and\n> >   test results.\n> > * A Windows build and test run takes up to 3h and TravisCI has a timeout\n> >   after 50min for Open Source projects. Since the TravisCI job does not\n> >   use heavy CPU/memory/etc. resources, the friendly TravisCI folks\n> >   extended the job timeout for git/git to 3h.\n> \n> The benefit is that Windows CI does not have to subscribe to the\n> GitHub repository to get notified (instead uses Travis as a relay\n> for update notification) and the result can be seen at the same\n> place as results on other platforms Travis natively support are\n> shown?  \n\nAlmost... Windows CI *cannot* subscribe to the GitHub repository, as only\nowners can install web hooks and give permission to update build status.\n\nBut yeah, you understand correctly: this innocuous change (along with a\nton of work I already finished on my side) allows us to let Travis trigger\nWindows build & test and to attach the log in the same place as the\nLinux/OSX results are already accessible.\n\n> > Things, that would need to be done:\n> > * Someone with write access to https://travis-ci.org/git/git would need\n> >   to add the secret token as \"GFW_CI_TOKEN\" variable in the TravisCI\n> >   repository setting [1]. Afterwards the build should just work.\n> \n> We need to make sure this does not leak to the execution log of\n> Travis.\n> \n> For example, in https://travis-ci.org/git/git/jobs/213616973, which\n> is a log of the documentation build for #1335.6 ran for the 'master'\n> branch, you can see \"ci/test-documentation.sh\" string appearing in\n> the log twice.  This comes from \"script:\" part, which is the same\n> mechanism this patch uses to invoke the new script with sekrit on\n> the command line.\n> \n> I am expecting that no expansion of \"$GFW_CI_TOKEN\" will be shown in\n> the output, but I've seen an incident where an unsuspecting 'set -x'\n> or '$cmd -v' revealed something that shouldn't have been made\n> public.  I want to make sure we are sure that the command line this\n> patch adds does not get echoed with expansion to the log.\n\nRight, typically there is a way in CI setups that marks certain strings as\nsecret and whenever they appear in the log, they will be blotted out.\n\n> Is GFW_CI_TOKEN known to be safe without double-quote around it, by\n> the way?\n\nYes, it is safe without double-quotes. I generated it using:\n\n\tdd if=/dev/urandom bs=20 count=1 2> /dev/null | base64\n\n> > Things, that might need to be done:\n> > * The Windows box can only process a single build at a time. A second\n> >   Windows build would need to wait until the first finishes.\n> \n> Perhaps instead of accumulating pending requests, perhaps we can\n> arrange so that Travis skips a build/test request that is not even\n> started yet for the same branch?  For branches that are never\n> rewound, a breakage in an earlier pushout would either show in a\n> later pushout of the same branch (if breakage is not fixed yet), or\n> doesn't (if the later pushout was to fix that breakage), and in\n> either case, it is not useful to test the earlier pushout when a\n> newer one is already available for testing.  For branches that are\n> constantly rewound, again, it is not useful to test the earlier\n> pushout when a newer one is already available for testing.\n\nYes, I think we have to use some kind of \"skip\" status if the build failed\nto run or finish in time. But I thought that the \"timeout\" status would\nfulfill that desire...\n\nCiao,\nDscho\n"},{"id":"315134","messageId":"20170323180134.geoyvq7qbm5vujo6@sigill.intra.peff.net","threadId":"45462","inReplyTo":"alpine.DEB.2.20.1703231716320.3767@virtualbox","subject":"Re: [PATCH v1] travis-ci: build and test Git on Windows","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-03-23T18:01:34Z","receivedAt":"2017-03-23T18:01:41Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 23, 2017 at 05:22:51PM +0100, Johannes Schindelin wrote:\n\n> > The benefit is that Windows CI does not have to subscribe to the\n> > GitHub repository to get notified (instead uses Travis as a relay\n> > for update notification) and the result can be seen at the same\n> > place as results on other platforms Travis natively support are\n> > shown?  \n> \n> Almost... Windows CI *cannot* subscribe to the GitHub repository, as only\n> owners can install web hooks and give permission to update build status.\n> \n> But yeah, you understand correctly: this innocuous change (along with a\n> ton of work I already finished on my side) allows us to let Travis trigger\n> Windows build & test and to attach the log in the same place as the\n> Linux/OSX results are already accessible.\n\nI don't mind adding a webhook if it helps. If I understand correctly\nthat would just handle the notification site. But then if the Windows\nbuild status were public, we could have Travis simply fetch it to keep\nthe build reports all together, without having to worry about a secret\ntoken.\n\nI don't mind proceeding with the secret token, though. You're the owner\nof the service the token accesses, so if you're comfortable with it, I\nam.\n\n> > > Things, that would need to be done:\n> > > * Someone with write access to https://travis-ci.org/git/git would need\n> > >   to add the secret token as \"GFW_CI_TOKEN\" variable in the TravisCI\n> > >   repository setting [1]. Afterwards the build should just work.\n> > \n> > We need to make sure this does not leak to the execution log of\n> > Travis.\n> [...]\n> \n> Right, typically there is a way in CI setups that marks certain strings as\n> secret and whenever they appear in the log, they will be blotted out.\n\nI think both Junio and I have access to the Travis config. Travis does\nhave a \"this is secret\" flag for setup config. But I think we'd need to\nverify that running the Travis build does not leak the variable in any\nother way.\n\nFor instance, if it's in the environment, can I push up a branch that\ndoes \"set | grep GFW_CI_TOKEN\", open a PR, and see it? I don't know the\nanswer.\n\n-Peff\n"},{"id":"315137","messageId":"281F3580-6FC4-40C2-95A6-D8AD2CCF2E54@gmail.com","threadId":"45462","inReplyTo":"alpine.DEB.2.20.1703221641070.3767@virtualbox","subject":"Re: [PATCH v1] travis-ci: build and test Git on Windows","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2017-03-23T18:19:14Z","receivedAt":"2017-03-23T18:19:21Z","isPatch":true,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\n> On 22 Mar 2017, at 16:49, Johannes Schindelin <johannes.schindelin@gmx.de> wrote:\n> \n> Hi Lars,\n> \n> On Wed, 22 Mar 2017, Lars Schneider wrote:\n...\n>> +\n>> +gfwci () {\n>> +\tcurl \\\n>> +\t\t-H \"Authentication: Bearer $TOKEN\" \\\n>> +\t\t--silent --retry 5 \\\n>> +\t\t\"https://git-for-windows-ci.azurewebsites.net/api/TestNow?$1\" |\n>> +\tsed \"$(printf '1s/^\\xef\\xbb\\xbf//')\"  # Remove the Byte Order Mark\n>> +}\n>> +\n>> +# Trigger build job\n>> +BUILD_ID=$(gfwci \"action=trigger&branch=$BRANCH&commit=$COMMIT&skipTests=false\")\n>> +\n>> +# Check if the $BUILD_ID contains a number\n>> +case $BUILD_ID in\n>> +\t''|*[!0-9]*) echo $BUILD_ID && exit 1\n> \n> Error messages are delivered that way, and they do not start with digits,\n> true. But maybe there is an exit status to indicate to Travis that we\n> cannot decide whether the build failed or succeeded in that case? The most\n> common cause for an error here is that the VM I use for testing is down\n> (which happens every once in a while to save on resources, and I have to\n> manually restart it)...\n\nCurl can return the HTTP code... I'll try to find a way to check for this.\n\n> \n>> +echo \"Visual Studio Team Services Build #${BUILD_ID}\"\n> \n> Nice plug, thanks! ;-)\n> \n>> +# Wait until build job finished\n>> +STATUS=\n>> +RESULT=\n>> +while true\n>> +do\n>> +\tLAST_STATUS=$STATUS\n>> +\tSTATUS=$(gfwci \"action=status&buildId=$BUILD_ID\")\n>> +\t[ \"$STATUS\" == \"$LAST_STATUS\" ] || printf \"\\nStatus: $STATUS \"\n>> +\tprintf \".\"\n>> +\n>> +\tcase $STATUS in\n>> +\t\tinProgress|postponed|notStarted) sleep 10                      ;; # continue\n>> +\t\t         \"completed: succeeded\") RESULT=\"success\";        break;; # success\n>> +\t\t                              *) echo \"Unknown: $STATUS\"; break;; # failure\n> \n> Well, there are more values for the status, and we know them, but we do\n> not handle them. Maybe \"Unhandled status:\"?\n\nSure! I'll fix that in v2 :-)\n\n- Lars"},{"id":"315141","messageId":"2713C936-BF9A-47E0-9169-3D6F634907EE@gmail.com","threadId":"45462","inReplyTo":"xmqqwpbhjej6.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v1] travis-ci: build and test Git on Windows","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2017-03-23T18:23:27Z","receivedAt":"2017-03-23T18:23:36Z","isPatch":true,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\n> On 22 Mar 2017, at 20:29, Junio C Hamano <gitster@pobox.com> wrote:\n> \n> Lars Schneider <larsxschneider@gmail.com> writes:\n> \n>> Therefore, we did the following:\n>> * Johannes Schindelin set up a Visual Studio Team Services build\n>>  sponsored by Microsoft and made it accessible via an Azure Function\n>>  that speaks a super-simple API. We made TravisCI use this API to\n>>  trigger a build, wait until its completion, and print the build and\n>>  test results.\n>> * A Windows build and test run takes up to 3h and TravisCI has a timeout\n>>  after 50min for Open Source projects. Since the TravisCI job does not\n>>  use heavy CPU/memory/etc. resources, the friendly TravisCI folks\n>>  extended the job timeout for git/git to 3h.\n> \n> The benefit is that Windows CI does not have to subscribe to the\n> GitHub repository to get notified (instead uses Travis as a relay\n> for update notification) and the result can be seen at the same\n> place as results on other platforms Travis natively support are\n> shown?  \nCorrect!\n\n> Very nice.\n\nThanks :-)\n\n\n>> Things, that would need to be done:\n>> * Someone with write access to https://travis-ci.org/git/git would need\n>>  to add the secret token as \"GFW_CI_TOKEN\" variable in the TravisCI\n>>  repository setting [1]. Afterwards the build should just work.\n> \n> We need to make sure this does not leak to the execution log of\n> Travis.\n\nTrue. I think I took care of this and it should not leak!\n\n\n>> Things, that might need to be done:\n>> * The Windows box can only process a single build at a time. A second\n>>  Windows build would need to wait until the first finishes.\n> \n> Perhaps instead of accumulating pending requests, perhaps we can\n> arrange so that Travis skips a build/test request that is not even\n> started yet for the same branch?  For branches that are never\n> rewound, a breakage in an earlier pushout would either show in a\n> later pushout of the same branch (if breakage is not fixed yet), or\n> doesn't (if the later pushout was to fix that breakage), and in\n> either case, it is not useful to test the earlier pushout when a\n> newer one is already available for testing.  For branches that are\n> constantly rewound, again, it is not useful to test the earlier\n> pushout when a newer one is already available for testing.\n\nWell, look at this. TravisCi *just* released a solution to\nexactly that problem! Good timing!\nhttps://blog.travis-ci.com/2017-03-22-introducing-auto-cancellation\n\n\n>> diff --git a/ci/run-windows-build.sh b/ci/run-windows-build.sh\n>> new file mode 100755\n>> index 0000000000..324a9ea4e6\n>> --- /dev/null\n>> +++ b/ci/run-windows-build.sh\n>> @@ -0,0 +1,55 @@\n>> +#!/usr/bin/env bash\n> \n> I know this is not a usual scripted Porcelain that must be usable by\n> all users, but I do not see anything that requires bash-ism in the\n> script.  Can we just do \"#!/bin/sh\", avoid bash-isms, and follow the\n> usual coding guidelines in general?\n\nSure!\n\n\n>> +[ $# -eq 3 ] || (echo \"Unexpected number of parameters\" && exit 1)\n> \n> i.e.e.g \"test $# = 3\" || ...\n> \n>> +# Check if the $BUILD_ID contains a number\n>> +case $BUILD_ID in\n>> +\t''|*[!0-9]*) echo $BUILD_ID && exit 1\n>> +esac\n> \n> Too deep an indent of a case arm, i.e. align them with case/esac, like\n> \n>        case $BUILD_ID in\n>        ''|*[!0-9]*) echo $BUILD_ID && exit 1\n>        esac\n\nWill do in v2!\n\n\nThanks,\nLars\n"},{"id":"315149","messageId":"xmqqbmsrdcz4.fsf@gitster.mtv.corp.google.com","threadId":"45462","inReplyTo":"20170323180134.geoyvq7qbm5vujo6@sigill.intra.peff.net","subject":"Re: [PATCH v1] travis-ci: build and test Git on Windows","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-03-23T19:12:15Z","receivedAt":"2017-03-23T19:12:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> For instance, if it's in the environment, can I push up a branch that\n> does \"set | grep GFW_CI_TOKEN\", open a PR, and see it? I don't know the\n> answer.\n\nI think the documentation said\n\n    Variables defined in repository settings are the same for all\n    builds, and when you restart an old build, it uses the latest\n    values. These variables are not automatically available to\n    forks.\n\nso we should be safe as long as we do not build against PRs.\n\nOn the other hand, perhaps a contributor may want to build and test\nhis own PR that may affect Windows platform, and such a contributor\nmay be helped if the main repository sets things up to build against\nPRs.  \n\nI personally think it is a separate issue and we shouldn't set it up\nto build against PRs.  If Windows CI wants to help these\ncontributors, it can give out the token to them, without relying on\nthe travis setup for the main repository.\n\n\nhttps://docs.travis-ci.com/user/environment-variables#Defining-Variables-in-Repository-Settings\n"},{"id":"315150","messageId":"xmqq7f3fdcsx.fsf@gitster.mtv.corp.google.com","threadId":"45462","inReplyTo":"20170323180134.geoyvq7qbm5vujo6@sigill.intra.peff.net","subject":"Re: [PATCH v1] travis-ci: build and test Git on Windows","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-03-23T19:15:58Z","receivedAt":"2017-03-23T19:16:05Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> I think both Junio and I have access to the Travis config. Travis does\n> have a \"this is secret\" flag for setup config. But I think we'd need to\n> verify that running the Travis build does not leak the variable in any\n> other way.\n\nI am not sure if I want to \"Authorize application\" at the GitHub\nsite to give Travis that broad set of permissions, though.  That is\nwhy I do not \"log in with GitHub\" to Travis.\n\nI just logged into Travis and it seems to me that git/git is set to\nbuild branch updates (which sounds sensible) and also is set to\nbuild pull request updates.  That somehow sounds like a dangerous\nmix with the \"secret environment variables\" thing, at least to me.\n\n> For instance, if it's in the environment, can I push up a branch that\n> does \"set | grep GFW_CI_TOKEN\", open a PR, and see it? I don't know the\n> answer.\n"},{"id":"315151","messageId":"20170323191721.7r5vrixtnx3cngdc@sigill.intra.peff.net","threadId":"45462","inReplyTo":"xmqqbmsrdcz4.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v1] travis-ci: build and test Git on Windows","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-03-23T19:17:21Z","receivedAt":"2017-03-23T19:17:29Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 23, 2017 at 12:12:15PM -0700, Junio C Hamano wrote:\n\n> Jeff King <peff@peff.net> writes:\n> \n> > For instance, if it's in the environment, can I push up a branch that\n> > does \"set | grep GFW_CI_TOKEN\", open a PR, and see it? I don't know the\n> > answer.\n> \n> I think the documentation said\n> \n>     Variables defined in repository settings are the same for all\n>     builds, and when you restart an old build, it uses the latest\n>     values. These variables are not automatically available to\n>     forks.\n> \n> so we should be safe as long as we do not build against PRs.\n\nI think we do build against PRs now. E.g.:\n\n  https://travis-ci.org/git/git/builds/213896051\n\nBut it looks like we can turn that off.\n\n> On the other hand, perhaps a contributor may want to build and test\n> his own PR that may affect Windows platform, and such a contributor\n> may be helped if the main repository sets things up to build against\n> PRs.\n> \n> I personally think it is a separate issue and we shouldn't set it up\n> to build against PRs.  If Windows CI wants to help these\n> contributors, it can give out the token to them, without relying on\n> the travis setup for the main repository.\n\nHrm, it does mean that people have no way to test on Windows until the\nbranch hits pu. Which is not ideal.\n\n-Peff\n"},{"id":"315154","messageId":"FE4A3F88-0B86-4069-B141-2DFB9C4E269E@gmail.com","threadId":"45462","inReplyTo":"20170323191721.7r5vrixtnx3cngdc@sigill.intra.peff.net","subject":"Re: [PATCH v1] travis-ci: build and test Git on Windows","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2017-03-23T19:26:15Z","receivedAt":"2017-03-23T19:26:23Z","isPatch":true,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\n> On 23 Mar 2017, at 20:17, Jeff King <peff@peff.net> wrote:\n> \n> On Thu, Mar 23, 2017 at 12:12:15PM -0700, Junio C Hamano wrote:\n> \n>> Jeff King <peff@peff.net> writes:\n>> \n>>> For instance, if it's in the environment, can I push up a branch that\n>>> does \"set | grep GFW_CI_TOKEN\", open a PR, and see it? I don't know the\n>>> answer.\n>> \n>> I think the documentation said\n>> \n>>    Variables defined in repository settings are the same for all\n>>    builds, and when you restart an old build, it uses the latest\n>>    values. These variables are not automatically available to\n>>    forks.\n>> \n>> so we should be safe as long as we do not build against PRs.\n> \n> I think we do build against PRs now. E.g.:\n> \n>  https://travis-ci.org/git/git/builds/213896051\n> \n> But it looks like we can turn that off.\n\nWhen we add a secret variable, then TravisCI will not build Pull Requests\nfor git/git anymore:\n\n\"[...] we do not provide these values to untrusted builds, \ntriggered by pull requests from another repository.\"\n\nSee: https://docs.travis-ci.com/user/environment-variables/#Defining-Variables-in-Repository-Settings\n\nHowever, I don't think that is a big deal because git/git doesn't\nsupport Pull Requests anyways. Plus, if a contributor is interested\nin TravisCI results, then the contributor can setup TravisCI for\ntheir own fork easily.\n\n\n>> On the other hand, perhaps a contributor may want to build and test\n>> his own PR that may affect Windows platform, and such a contributor\n>> may be helped if the main repository sets things up to build against\n>> PRs.\n>> \n>> I personally think it is a separate issue and we shouldn't set it up\n>> to build against PRs.  If Windows CI wants to help these\n>> contributors, it can give out the token to them, without relying on\n>> the travis setup for the main repository.\n> \n> Hrm, it does mean that people have no way to test on Windows until the\n> branch hits pu. Which is not ideal.\n\nI agree it's not ideal. But I think it is an improvement to check\npu/next/master/maint continuously :-)\n\n\nCheers,\nLars"},{"id":"315156","messageId":"xmqqzigbbxjq.fsf@gitster.mtv.corp.google.com","threadId":"45462","inReplyTo":"FE4A3F88-0B86-4069-B141-2DFB9C4E269E@gmail.com","subject":"Re: [PATCH v1] travis-ci: build and test Git on Windows","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-03-23T19:30:49Z","receivedAt":"2017-03-23T19:31:02Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Lars Schneider <larsxschneider@gmail.com> writes:\n\n> \"[...] we do not provide these values to untrusted builds, \n> triggered by pull requests from another repository.\"\n>\n> See: https://docs.travis-ci.com/user/environment-variables/#Defining-Variables-in-Repository-Settings\n\nOK, it is a releaf to see an indication that somebody over there is\nthinking.  Thanks.\n\nSo we do _not_ have to turn it off; as soon as we define sekrit\nvariables, they will turn it off for us ;-).\n\n>> Hrm, it does mean that people have no way to test on Windows until the\n>> branch hits pu. Which is not ideal.\n>\n> I agree it's not ideal. But I think it is an improvement to check\n> pu/next/master/maint continuously :-)\n\nI am not sure what you mean.  We are building each and every branch\nupdates already, and I do not see any improvement over what we are\ndoing now.  Care to elaborate?\n"},{"id":"315159","messageId":"81C8DFC7-53DA-4533-8005-F6D8D643FDA2@gmail.com","threadId":"45462","inReplyTo":"xmqqzigbbxjq.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v1] travis-ci: build and test Git on Windows","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2017-03-23T19:36:12Z","receivedAt":"2017-03-23T19:36:19Z","isPatch":true,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\n> On 23 Mar 2017, at 20:30, Junio C Hamano <gitster@pobox.com> wrote:\n> \n> Lars Schneider <larsxschneider@gmail.com> writes:\n> \n>> \"[...] we do not provide these values to untrusted builds, \n>> triggered by pull requests from another repository.\"\n>> \n>> See: https://docs.travis-ci.com/user/environment-variables/#Defining-Variables-in-Repository-Settings\n> \n> OK, it is a releaf to see an indication that somebody over there is\n> thinking.  Thanks.\n> \n> So we do _not_ have to turn it off; as soon as we define sekrit\n> variables, they will turn it off for us ;-).\n> \n>>> Hrm, it does mean that people have no way to test on Windows until the\n>>> branch hits pu. Which is not ideal.\n>> \n>> I agree it's not ideal. But I think it is an improvement to check\n>> pu/next/master/maint continuously :-)\n> \n> I am not sure what you mean.  We are building each and every branch\n> updates already, and I do not see any improvement over what we are\n> doing now.  Care to elaborate?\n\nWe are building each and every branch on TravisCI right now - but \nonly on Linux and OSX. With this change we also build it on\nWindows. That should help to spot Windows related issues more\nquickly I think.\n\n- Lars\n\n"},{"id":"315161","messageId":"20170323193823.gxodwqv4eshgtqbc@sigill.intra.peff.net","threadId":"45462","inReplyTo":"FE4A3F88-0B86-4069-B141-2DFB9C4E269E@gmail.com","subject":"Re: [PATCH v1] travis-ci: build and test Git on Windows","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-03-23T19:38:23Z","receivedAt":"2017-03-23T19:38:38Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 23, 2017 at 08:26:15PM +0100, Lars Schneider wrote:\n\n> > I think we do build against PRs now. E.g.:\n> > \n> >  https://travis-ci.org/git/git/builds/213896051\n> > \n> > But it looks like we can turn that off.\n> \n> When we add a secret variable, then TravisCI will not build Pull Requests\n> for git/git anymore:\n> \n> \"[...] we do not provide these values to untrusted builds, \n> triggered by pull requests from another repository.\"\n> \n> See: https://docs.travis-ci.com/user/environment-variables/#Defining-Variables-in-Repository-Settings\n\nAh, OK, that makes sense. So we would only have to worry about our _own_\ncode accidentally disclosing it. But that should be easy to look for by\ngrepping the log (did somebody do that?).\n\n> However, I don't think that is a big deal because git/git doesn't\n> support Pull Requests anyways. Plus, if a contributor is interested\n> in TravisCI results, then the contributor can setup TravisCI for\n> their own fork easily.\n\nYeah, agreed. It's not like we are blocking the merge button with a\nfailing status.\n\n> > Hrm, it does mean that people have no way to test on Windows until the\n> > branch hits pu. Which is not ideal.\n> \n> I agree it's not ideal. But I think it is an improvement to check\n> pu/next/master/maint continuously :-)\n\nOh, I agree this is a step forward from the status quo. I just wondered\nif we could do even better.\n\nAs a side note, I've started having travis run on all of the topic\nbranches in peff/git, with the idea to get early feedback on OS X\nproblems (and now hopefully Windows ones). My two issues so far are:\n\n  - I have a lot of work-in-progress branches. I put \"-wip\" at the end\n    of the branch name for my own scripts. It looks like I can put \"[ci\n    skip]\" in the commit subject to convince Travis to skip them, but\n    that's a little annoying. Is there any way to skip based on just the\n    branch name? I couldn't find one.\n\n  - The OS X builds seem to regularly time out. That at least marks a\n    \"!\" in the build status screen instead of an \"X\", but it's a lot of\n    noise (and it misses the point for me, which is testing on OS X; I\n    already build regularly on Linux).\n\n-Peff\n"},{"id":"315164","messageId":"3CC8E237-86EA-4F35-A03E-15BED5869403@gmail.com","threadId":"45462","inReplyTo":"20170323193823.gxodwqv4eshgtqbc@sigill.intra.peff.net","subject":"Re: [PATCH v1] travis-ci: build and test Git on Windows","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2017-03-23T20:00:33Z","receivedAt":"2017-03-23T20:00:43Z","isPatch":true,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\n> On 23 Mar 2017, at 20:38, Jeff King <peff@peff.net> wrote:\n> \n> On Thu, Mar 23, 2017 at 08:26:15PM +0100, Lars Schneider wrote:\n> \n>>> I think we do build against PRs now. E.g.:\n>>> \n>>> https://travis-ci.org/git/git/builds/213896051\n>>> \n>>> But it looks like we can turn that off.\n>> \n>> When we add a secret variable, then TravisCI will not build Pull Requests\n>> for git/git anymore:\n>> \n>> \"[...] we do not provide these values to untrusted builds, \n>> triggered by pull requests from another repository.\"\n>> \n>> See: https://docs.travis-ci.com/user/environment-variables/#Defining-Variables-in-Repository-Settings\n> \n> Ah, OK, that makes sense. So we would only have to worry about our _own_\n> code accidentally disclosing it. But that should be easy to look for by\n> grepping the log (did somebody do that?).\n\nThis is how a successful Windows build would look like:\nhttps://travis-ci.org/larsxschneider/git/jobs/214391822\n\nDscho's token is not in the log.\n\n\n>> However, I don't think that is a big deal because git/git doesn't\n>> support Pull Requests anyways. Plus, if a contributor is interested\n>> in TravisCI results, then the contributor can setup TravisCI for\n>> their own fork easily.\n> \n> Yeah, agreed. It's not like we are blocking the merge button with a\n> failing status.\n> \n>>> Hrm, it does mean that people have no way to test on Windows until the\n>>> branch hits pu. Which is not ideal.\n>> \n>> I agree it's not ideal. But I think it is an improvement to check\n>> pu/next/master/maint continuously :-)\n> \n> Oh, I agree this is a step forward from the status quo. I just wondered\n> if we could do even better.\n> \n> As a side note, I've started having travis run on all of the topic\n> branches in peff/git, with the idea to get early feedback on OS X\n> problems (and now hopefully Windows ones). My two issues so far are:\n> \n>  - I have a lot of work-in-progress branches. I put \"-wip\" at the end\n>    of the branch name for my own scripts. It looks like I can put \"[ci\n>    skip]\" in the commit subject to convince Travis to skip them, but\n>    that's a little annoying. Is there any way to skip based on just the\n>    branch name? I couldn't find one.\n\nWe can blacklist these branches with a regex in the travis.yml:\nhttps://docs.travis-ci.com/user/customizing-the-build#Building-Specific-Branches\n\n\n>  - The OS X builds seem to regularly time out. That at least marks a\n>    \"!\" in the build status screen instead of an \"X\", but it's a lot of\n>    noise (and it misses the point for me, which is testing on OS X; I\n>    already build regularly on Linux).\n\nWell, I guess the reason is that OSX is a bit harder to virtualize \ncompared to Linux. In general on git/git the OSX builds are OK.\n\nI build a little stats page to visualize the results over time:\nhttps://larsxschneider.github.io/git-ci-stats/\n\nWe have 2 OSX jobs and 2 Linux jobs per build. I am usually only\ndigging into issues if both jobs are red.\n\nMaybe TravisCI throttles your usage somehow as you push a lot of commits?\n\nKeep in mind, all the TravisCI compute hours are free... considering\nthat I think it is quite OK :-)\n\n- Lars"},{"id":"315168","messageId":"xmqqfui3bvpe.fsf@gitster.mtv.corp.google.com","threadId":"45462","inReplyTo":"81C8DFC7-53DA-4533-8005-F6D8D643FDA2@gmail.com","subject":"Re: [PATCH v1] travis-ci: build and test Git on Windows","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-03-23T20:10:37Z","receivedAt":"2017-03-23T20:11:29Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Lars Schneider <larsxschneider@gmail.com> writes:\n\n>>> I agree it's not ideal. But I think it is an improvement to check\n>>> pu/next/master/maint continuously :-)\n>> \n>> I am not sure what you mean.  We are building each and every branch\n>> updates already, and I do not see any improvement over what we are\n>> doing now.  Care to elaborate?\n>\n> We are building each and every branch on TravisCI right now - but \n> only on Linux and OSX. With this change we also build it on\n> Windows. That should help to spot Windows related issues more\n> quickly I think.\n\nWe are losing the build for PR for folks who later submit patches as\nthe price for that.  \"building each and every branch\" stay constant\nand the trade-off is between building four integration branches on\nWindows and allowing contributors to easily check their work early.\n\nIf your \"But I think it is an improvement\" was followed by \"to check\nthe four branches on Windows continuously\", though, I wouldn't have\nhad to ask the question, as I tend to agree it is a better trade\noff.\n\nThanks.\n\n\n"},{"id":"315169","messageId":"xmqqbmsrbvf3.fsf@gitster.mtv.corp.google.com","threadId":"45462","inReplyTo":"20170322065612.18797-1-larsxschneider@gmail.com","subject":"Re: [PATCH v1] travis-ci: build and test Git on Windows","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-03-23T20:16:48Z","receivedAt":"2017-03-23T20:16:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Lars Schneider <larsxschneider@gmail.com> writes:\n\n> Things, that would need to be done:\n> * Someone with write access to https://travis-ci.org/git/git would need\n>   to add the secret token as \"GFW_CI_TOKEN\" variable in the TravisCI\n>   repository setting [1]. Afterwards the build should just work.\n\nAs coordinating the timing of when this happens with the timing when\nmerging this topic to 'pu' happens is an unnecessary cognitive\nburden, can you make a small change to this part:\n\n> +      script:\n> +        - >\n> +          test \"$TRAVIS_REPO_SLUG\" != \"git/git\" ||\n\nAdd\n\ttest -z \"$GFW_CI_TOKEN\" ||\n\nhere, so that the sript is not run while \"Someone with write access\"\nhasn't got around to doing it. \n\n> +          ci/run-windows-build.sh $GFW_CI_TOKEN $TRAVIS_BRANCH $(git rev-parse HEAD)\n\nIt would still be a good idea to dq all these $VARIABLE and\n$(COMMAND OUTPUT) references, as the script expects three\nparameters.\n\n> + ...\n> +[ $# -eq 3 ] || (echo \"Unexpected number of parameters\" && exit 1)\n\nThanks.\n"},{"id":"315170","messageId":"20170323202002.lfpuglqawz4ooruw@sigill.intra.peff.net","threadId":"45462","inReplyTo":"3CC8E237-86EA-4F35-A03E-15BED5869403@gmail.com","subject":"Re: [PATCH v1] travis-ci: build and test Git on Windows","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-03-23T20:20:03Z","receivedAt":"2017-03-23T20:20:36Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 23, 2017 at 09:00:33PM +0100, Lars Schneider wrote:\n\n> > Ah, OK, that makes sense. So we would only have to worry about our _own_\n> > code accidentally disclosing it. But that should be easy to look for by\n> > grepping the log (did somebody do that?).\n> \n> This is how a successful Windows build would look like:\n> https://travis-ci.org/larsxschneider/git/jobs/214391822\n> \n> Dscho's token is not in the log.\n\nGreat, thank you for double-checking.\n\n> >  - I have a lot of work-in-progress branches. I put \"-wip\" at the end\n> >    of the branch name for my own scripts. It looks like I can put \"[ci\n> >    skip]\" in the commit subject to convince Travis to skip them, but\n> >    that's a little annoying. Is there any way to skip based on just the\n> >    branch name? I couldn't find one.\n> \n> We can blacklist these branches with a regex in the travis.yml:\n> https://docs.travis-ci.com/user/customizing-the-build#Building-Specific-Branches\n\nI had a feeling it might be something like that. So we would all need to\nagree on the convention for WIP branch names. If other people like the\nidea, I'm happy to make a patch, but I don't want to impose my own weird\nconventions on everyone else.\n\n> Maybe TravisCI throttles your usage somehow as you push a lot of commits?\n\nCould be. Looking at:\n\n  https://travis-ci.org/peff/git/branches\n\nIt seems to timeout on over half the branches (in fact, there are only a\nfew that passed all of the tests). My pattern is particularly spiky from\nTravis's perspective, because once a day I rebase everything on top of\nmaster and push them the whole thing in a bunch. So they 75 branches,\nall at once. That seems like it would be ripe for throttling (though I\nwould much rather they just queue the builds and do them one at a time).\n\n> Keep in mind, all the TravisCI compute hours are free... considering\n> that I think it is quite OK :-)\n\nI don't blame Travis at all. But if the tool does not produce reliable\nresults, then I will start to ignore it. And somebody on this thread\n(not you) has been complaining repeatedly about developers ignoring CI\nresults.\n\n-Peff\n"},{"id":"315171","messageId":"xmqq7f3fbury.fsf@gitster.mtv.corp.google.com","threadId":"45462","inReplyTo":"20170323202002.lfpuglqawz4ooruw@sigill.intra.peff.net","subject":"Re: [PATCH v1] travis-ci: build and test Git on Windows","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-03-23T20:30:41Z","receivedAt":"2017-03-23T20:30:49Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n>> We can blacklist these branches with a regex in the travis.yml:\n>> https://docs.travis-ci.com/user/customizing-the-build#Building-Specific-Branches\n>\n> I had a feeling it might be something like that. So we would all need to\n> agree on the convention for WIP branch names. If other people like the\n> idea, I'm happy to make a patch, but I don't want to impose my own weird\n> conventions on everyone else.\n\nI can go with any convention, but I'd be more pleased if you made\nsure that \"do not build this with CI\" and \"this is WIP\" are kept as\ntwo separate concepts, as I can see having some WIP that I do want\nto get tested.\n\nPerhaps a substring \"/noci-\" anywhere in the branch name, or\nsomething silly like that?\n\n> I don't blame Travis at all. But if the tool does not produce reliable\n> results, then I will start to ignore it.\n\nYes, that is a real issue.  I was wondering if we can have a knob\nthat can be controled with the repository setting to limit which\n\"build jobs\" are run, so that you can use that web UI to set an\n\"environment variable\" that lists only .3 and .4 (which correspond\nto these two OSX builds) and .travis.yml takes notice of the\nvariable setting, or something.\n"},{"id":"315174","messageId":"CEE52E60-F31F-4BA9-BA79-7526EE6C5397@gmail.com","threadId":"45462","inReplyTo":"20170323202002.lfpuglqawz4ooruw@sigill.intra.peff.net","subject":"Re: [PATCH v1] travis-ci: build and test Git on Windows","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2017-03-23T20:39:14Z","receivedAt":"2017-03-23T20:39:22Z","isPatch":true,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\n> On 23 Mar 2017, at 21:20, Jeff King <peff@peff.net> wrote:\n> \n> On Thu, Mar 23, 2017 at 09:00:33PM +0100, Lars Schneider wrote:\n> \n>>> Ah, OK, that makes sense. So we would only have to worry about our _own_\n>>> code accidentally disclosing it. But that should be easy to look for by\n>>> grepping the log (did somebody do that?).\n>> \n>> This is how a successful Windows build would look like:\n>> https://travis-ci.org/larsxschneider/git/jobs/214391822\n>> \n>> Dscho's token is not in the log.\n> \n> Great, thank you for double-checking.\n\nI can see that one could think that this variables leaks, though. \nI think in v2 I won't pass the token as parameter. The token \nvariable is an environment variable anyways and I can just use\nit in the script.\n\n\n>>> - I have a lot of work-in-progress branches. I put \"-wip\" at the end\n>>>   of the branch name for my own scripts. It looks like I can put \"[ci\n>>>   skip]\" in the commit subject to convince Travis to skip them, but\n>>>   that's a little annoying. Is there any way to skip based on just the\n>>>   branch name? I couldn't find one.\n>> \n>> We can blacklist these branches with a regex in the travis.yml:\n>> https://docs.travis-ci.com/user/customizing-the-build#Building-Specific-Branches\n> \n> I had a feeling it might be something like that. So we would all need to\n> agree on the convention for WIP branch names. If other people like the\n> idea, I'm happy to make a patch, but I don't want to impose my own weird\n> conventions on everyone else.\n\nThis makes sense to me. If someone complains with a good argument then\nwe can still revert it.\n\n\n>> Maybe TravisCI throttles your usage somehow as you push a lot of commits?\n> \n> Could be. Looking at:\n> \n>  https://travis-ci.org/peff/git/branches\n> \n> It seems to timeout on over half the branches (in fact, there are only a\n> few that passed all of the tests). My pattern is particularly spiky from\n> Travis's perspective, because once a day I rebase everything on top of\n> master and push them the whole thing in a bunch. So they 75 branches,\n> all at once. That seems like it would be ripe for throttling (though I\n> would much rather they just queue the builds and do them one at a time).\n\nCould you try to set this to 7 or less in your TravisCI?\nhttps://docs.travis-ci.com/user/customizing-the-build#Limiting-Concurrent-Builds\n\nI am curious if this improves the situation.\n\n- Lars"},{"id":"315176","messageId":"20170323204114.ui7jqrd3guwc3sgl@sigill.intra.peff.net","threadId":"45462","inReplyTo":"xmqq7f3fbury.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v1] travis-ci: build and test Git on Windows","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-03-23T20:41:14Z","receivedAt":"2017-03-23T20:41:28Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 23, 2017 at 01:30:41PM -0700, Junio C Hamano wrote:\n\n> >> We can blacklist these branches with a regex in the travis.yml:\n> >> https://docs.travis-ci.com/user/customizing-the-build#Building-Specific-Branches\n> >\n> > I had a feeling it might be something like that. So we would all need to\n> > agree on the convention for WIP branch names. If other people like the\n> > idea, I'm happy to make a patch, but I don't want to impose my own weird\n> > conventions on everyone else.\n> \n> I can go with any convention, but I'd be more pleased if you made\n> sure that \"do not build this with CI\" and \"this is WIP\" are kept as\n> two separate concepts, as I can see having some WIP that I do want\n> to get tested.\n> \n> Perhaps a substring \"/noci-\" anywhere in the branch name, or\n> something silly like that?\n\nHrm, most of the point for me was _not_ having to define the two\nconcepts separately. Let me try it for a while with \"[ci skip]\" in the\ntip commit subject, and see how painful I find that. My goal is\neventually to turn on notifications, so I'd quickly be reminded if I\nforgot such a marker.\n\n-Peff\n"},{"id":"315177","messageId":"20170323204253.etxrovhbxfmfve6s@sigill.intra.peff.net","threadId":"45462","inReplyTo":"CEE52E60-F31F-4BA9-BA79-7526EE6C5397@gmail.com","subject":"Re: [PATCH v1] travis-ci: build and test Git on Windows","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-03-23T20:42:54Z","receivedAt":"2017-03-23T20:43:00Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Mar 23, 2017 at 09:39:14PM +0100, Lars Schneider wrote:\n\n> > Could be. Looking at:\n> > \n> >  https://travis-ci.org/peff/git/branches\n> > \n> > It seems to timeout on over half the branches (in fact, there are only a\n> > few that passed all of the tests). My pattern is particularly spiky from\n> > Travis's perspective, because once a day I rebase everything on top of\n> > master and push them the whole thing in a bunch. So they 75 branches,\n> > all at once. That seems like it would be ripe for throttling (though I\n> > would much rather they just queue the builds and do them one at a time).\n> \n> Could you try to set this to 7 or less in your TravisCI?\n> https://docs.travis-ci.com/user/customizing-the-build#Limiting-Concurrent-Builds\n> \n> I am curious if this improves the situation.\n\nSure, that's easy enough to try. I'll let it go for a few days with that\nand see if it improves.\n\n-Peff\n"},{"id":"315178","messageId":"CAJZjrdVN6W_yyAuM9Sbr0qnCtZ77Z89XbJ_s-g5V7n5+kdsV5w@mail.gmail.com","threadId":"45462","inReplyTo":"20170323193823.gxodwqv4eshgtqbc@sigill.intra.peff.net","subject":"Re: [PATCH v1] travis-ci: build and test Git on Windows","fromName":"Samuel Lijin","fromEmail":"sxlijin@gmail.com","sentAt":"2017-03-23T21:04:03Z","receivedAt":"2017-03-23T21:05:18Z","isPatch":true,"sender":{"key":"sxlijin@gmail.com","avatar":"https://gravatar.com/avatar/01777bf1eae64e2b4dca97dcac182a6abbcf6fd8cb4d5b8fa33edf9f8cc21746?d=mp&s=160"},"body":"On Thu, Mar 23, 2017 at 2:38 PM, Jeff King <peff@peff.net> wrote:\n> On Thu, Mar 23, 2017 at 08:26:15PM +0100, Lars Schneider wrote:\n>\n>> > I think we do build against PRs now. E.g.:\n>> >\n>> >  https://travis-ci.org/git/git/builds/213896051\n>> >\n>> > But it looks like we can turn that off.\n>>\n>> When we add a secret variable, then TravisCI will not build Pull Requests\n>> for git/git anymore:\n>>\n>> \"[...] we do not provide these values to untrusted builds,\n>> triggered by pull requests from another repository.\"\n>>\n>> See: https://docs.travis-ci.com/user/environment-variables/#Defining-Variables-in-Repository-Settings\n>\n> Ah, OK, that makes sense. So we would only have to worry about our _own_\n> code accidentally disclosing it. But that should be easy to look for by\n> grepping the log (did somebody do that?).\n>\n>> However, I don't think that is a big deal because git/git doesn't\n>> support Pull Requests anyways. Plus, if a contributor is interested\n>> in TravisCI results, then the contributor can setup TravisCI for\n>> their own fork easily.\n>\n> Yeah, agreed. It's not like we are blocking the merge button with a\n> failing status.\n>\n>> > Hrm, it does mean that people have no way to test on Windows until the\n>> > branch hits pu. Which is not ideal.\n>>\n>> I agree it's not ideal. But I think it is an improvement to check\n>> pu/next/master/maint continuously :-)\n>\n> Oh, I agree this is a step forward from the status quo. I just wondered\n> if we could do even better.\n>\n> As a side note, I've started having travis run on all of the topic\n> branches in peff/git, with the idea to get early feedback on OS X\n> problems (and now hopefully Windows ones). My two issues so far are:\n>\n>   - I have a lot of work-in-progress branches. I put \"-wip\" at the end\n>     of the branch name for my own scripts. It looks like I can put \"[ci\n>     skip]\" in the commit subject to convince Travis to skip them, but\n>     that's a little annoying. Is there any way to skip based on just the\n>     branch name? I couldn't find one.\n\nI think you can \"safelist\" (whitelist) branches to build with regexes:\nhttps://docs.travis-ci.com/user/customizing-the-build#Building-Specific-Branches\n\n>   - The OS X builds seem to regularly time out. That at least marks a\n>     \"!\" in the build status screen instead of an \"X\", but it's a lot of\n>     noise (and it misses the point for me, which is testing on OS X; I\n>     already build regularly on Linux).\n\nI suspect this happens because they don't have a lot of macOS runners\n- I've seen those jobs wait for hours (even on private jobs) before a\nrunner gets freed up.\n\n> -Peff\n"},{"id":"315357","messageId":"alpine.DEB.2.20.1703250044500.3767@virtualbox","threadId":"45462","inReplyTo":"20170323202002.lfpuglqawz4ooruw@sigill.intra.peff.net","subject":"Re: [PATCH v1] travis-ci: build and test Git on Windows","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-03-24T23:50:01Z","receivedAt":"2017-03-24T23:50:17Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Peff,\n\nOn Thu, 23 Mar 2017, Jeff King wrote:\n\n> My pattern is particularly spiky from Travis's perspective, because once\n> a day I rebase everything on top of master and push them the whole thing\n> in a bunch. So they 75 branches, all at once. That seems like it would\n> be ripe for throttling (though I would much rather they just queue the\n> builds and do them one at a time).\n\nTravis is optimized for Continuous Integration, i.e. one or maybe two\nintegration branches that merge PRs every once in a while.\n\nWhat we would need is Continuous Testing, really, because we do not do\nContinuous Integration at all.\n\nOn the point of the sekrit variable: all I tried to do is to avoid\noverwhelming the (currently) single VM with plenty of jobs. If the build &\ntest would not take so darned long on Windows due to going in and out of\nthe POSIX emulation layer a gazillion times (caused by intense shell\nscripting), the tests could be faster. But that would require a massive\namount of work, and I simply have too much on my plate to take that task\non in addition.\n\nIf you have an idea how to prevent the overloading of the VM by any means\nthat does not involve that token, please tell me.\n\nCiao,\nDscho\n"}]}