{"thread":{"id":"47568","subject":"[PATCH] travis-ci: build Git during the 'script' phase","startedAt":"2018-01-08T17:22:35Z","lastAt":"2018-01-14T11:10:55Z","messageCount":10,"participants":["SZEDER Gábor","Junio C Hamano","Lars Schneider","Jeff King"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"336156","messageId":"20180108172214.23615-1-szeder.dev@gmail.com","threadId":"47568","inReplyTo":null,"subject":"[PATCH] travis-ci: build Git during the 'script' phase","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2018-01-08T17:22:14Z","receivedAt":"2018-01-08T17:22:35Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"Ever since we started building and testing Git on Travis CI (522354d70\n(Add Travis CI support, 2015-11-27)), we build Git in the\n'before_script' phase and run the test suite in the 'script' phase\n(except in the later introduced 32 bit Linux and Windows build jobs,\nwhere we build in the 'script' phase').\n\nContrarily, the Travis CI practice is to build and test in the\n'script' phase; indeed Travis CI's default build command for the\n'script' phase of C/C++ projects is:\n\n ./configure && make && make test\n\nThe reason why Travis CI does it this way and why it's a better\napproach than ours lies in how unsuccessful build jobs are\ncategorized. After something went wrong in a build job, its state can\nbe:\n\n - 'failed', if a command in the 'script' phase returned an error.\n This is indicated by a red 'X' on the Travis CI web interface.\n\n - 'errored', if a command in the 'before_install', 'install', or\n 'before_script' phase returned an error, or the build job exceeded\n the time limit. This is shown as a red '!' on the web interface.\n\nThis makes it easier, both for humans looking at the Travis CI web\ninterface and for automated tools querying the Travis CI API, to\ndecide when an unsuccessful build is our responsibility requiring\nhuman attention, i.e. when a build job 'failed' because of a compiler\nerror or a test failure, and when it's caused by something beyond our\ncontrol and might be fixed by restarting the build job, e.g. when a\nbuild job 'errored' because a dependency couldn't be installed due to\na temporary network error or because the OSX build job exceeded its\ntime limit.\n\nThe drawback of building Git in the 'before_script' phase is that one\nhas to check the trace log of all 'errored' build jobs, too, to see\nwhat caused the error, as it might have been caused by a compiler\nerror. This requires additional clicks and page loads on the web\ninterface and additional complexity and API requests in automated\ntools.\n\nTherefore, move building Git from the 'before_script' phase to the\n'script' phase, updating the script's name accordingly as well.\n'ci/run-builds.sh' now becomes basically empty, remove it. Several of\nour build job configurations override our default 'before_script' to\ndo nothing; with this change our default 'before_script' won't do\nanything, either, so remove those overriding directives as well.\n\nSigned-off-by: SZEDER Gábor \n---\n\nA verbose commit message for such a change... but I don't know why we\nstarted with building Git in the 'before_script' phase. 522354d70\ndoesn't tell, and I couldn't find anything relevant in the mailing list\narchives. Whatever the reasons might have been, I think the above\njustifies the change.\n\nShould go on top of 'sg/travis-check-untracked' in 'next'.\n\n .travis.yml | 7 +------\n ci/{run-tests.sh => run-build-and-tests.sh} | 4 +++-\n ci/run-build.sh | 8 --------\n 3 files changed, 4 insertions(+), 15 deletions(-)\n rename ci/{run-tests.sh => run-build-and-tests.sh} (80%)\n delete mode 100755 ci/run-build.sh\n\ndiff --git a/.travis.yml b/.travis.yml\nindex 4684b3f4f..5f5ee4f3b 100644\n--- a/.travis.yml\n+++ b/.travis.yml\n@@ -33,7 +33,6 @@ matrix:\n compiler:\n addons:\n before_install:\n- before_script:\n script:\n - >\n test \"$TRAVIS_REPO_SLUG\" != \"git/git\" ||\n@@ -46,7 +45,6 @@ matrix:\n services:\n - docker\n before_install:\n- before_script:\n script: ci/run-linux32-docker.sh\n - env: jobname=StaticAnalysis\n os: linux\n@@ -56,7 +54,6 @@ matrix:\n packages:\n - coccinelle\n before_install:\n- before_script:\n script: ci/run-static-analysis.sh\n after_failure:\n - env: jobname=Documentation\n@@ -68,13 +65,11 @@ matrix:\n - asciidoc\n - xmlto\n before_install:\n- before_script:\n script: ci/test-documentation.sh\n after_failure:\n \n before_install: ci/install-dependencies.sh\n-before_script: ci/run-build.sh\n-script: ci/run-tests.sh\n+script: ci/run-build-and-tests.sh\n after_failure: ci/print-test-failures.sh\n \n notifications:\ndiff --git a/ci/run-tests.sh b/ci/run-build-and-tests.sh\nsimilarity index 80%\nrename from ci/run-tests.sh\nrename to ci/run-build-and-tests.sh\nindex 22355f009..d3a094603 100755\n--- a/ci/run-tests.sh\n+++ b/ci/run-build-and-tests.sh\n@@ -1,11 +1,13 @@\n #!/bin/sh\n #\n-# Test Git\n+# Build and test Git\n #\n \n . ${0%/*}/lib-travisci.sh\n \n ln -s $HOME/travis-cache/.prove t/.prove\n+\n+make --jobs=2\n make --quiet test\n \n check_unignored_build_artifacts\ndiff --git a/ci/run-build.sh b/ci/run-build.sh\ndeleted file mode 100755\nindex 4f940d103..000000000\n--- a/ci/run-build.sh\n+++ /dev/null\n@@ -1,8 +0,0 @@\n-#!/bin/sh\n-#\n-# Build Git\n-#\n-\n-. ${0%/*}/lib-travisci.sh\n-\n-make --jobs=2\n-- \n2.16.0.rc1.67.g706959270\n\n"},{"id":"336207","messageId":"xmqqvagc6m42.fsf@gitster.mtv.corp.google.com","threadId":"47568","inReplyTo":"20180108172214.23615-1-szeder.dev@gmail.com","subject":"Re: [PATCH] travis-ci: build Git during the 'script' phase","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-01-08T22:07:09Z","receivedAt":"2018-01-08T22:07:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"SZEDER Gábor writes:\n\n> The reason why Travis CI does it this way and why it's a better\n> approach than ours lies in how unsuccessful build jobs are\n> categorized. ...\n> ...\n> This makes it easier, both for humans looking at the Travis CI web\n> interface and for automated tools querying the Travis CI API,...\n> ...\n> A verbose commit message for such a change... but I don't know why we\n> started with building Git in the 'before_script' phase.\n\nThanks for writing it up clearly. TBH, I didn't even realize that\nthere were meaningful distinctions between the two cases after\nseeing that sometimes our tests were failing and sometimes erroring\n;-)\n\n> Should go on top of 'sg/travis-check-untracked' in 'next'.\n"},{"id":"336212","messageId":"5DE3FA05-2347-4BE7-8A1A-A6E5FEEC7C2B@gmail.com","threadId":"47568","inReplyTo":"xmqqvagc6m42.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] travis-ci: build Git during the 'script' phase","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2018-01-08T22:38:44Z","receivedAt":"2018-01-08T22:38:56Z","isPatch":true,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\n> On 08 Jan 2018, at 23:07, Junio C Hamano wrote:\n> \n> SZEDER Gábor writes:\n> \n>> The reason why Travis CI does it this way and why it's a better\n>> approach than ours lies in how unsuccessful build jobs are\n>> categorized. ...\n>> ...\n>> This makes it easier, both for humans looking at the Travis CI web\n>> interface and for automated tools querying the Travis CI API,...\n>> ...\n>> A verbose commit message for such a change... but I don't know why we\n>> started with building Git in the 'before_script' phase.\n> \n> Thanks for writing it up clearly. TBH, I didn't even realize that\n> there were meaningful distinctions between the two cases after\n> seeing that sometimes our tests were failing and sometimes erroring\n> ;-)\n\nI understand the reasons for the proposed patch. However, I did this \nintentionally back then. Here is my reason:\n\nIf `make` is successful, then I am not interested in its output.\nLook at this run: https://travis-ci.org/szeder/git/jobs/324271623\n\nYou have to scroll down 1,406 lines to get to the test result \noutput (this is usually the interesting part).\n\nIf this is a valid argument for you, would it be an option to\npipe the verbose `make` output to a file and only print it in case\nof error (we do something similar for the tests already).\n\n- Lars"},{"id":"336504","messageId":"CAM0VKjnSzoc+E408ifKCg+qPTaGRNL3e3JVdRN573kdcBSzbHw@mail.gmail.com","threadId":"47568","inReplyTo":"5DE3FA05-2347-4BE7-8A1A-A6E5FEEC7C2B@gmail.com","subject":"Re: [PATCH] travis-ci: build Git during the 'script' phase","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2018-01-12T13:32:54Z","receivedAt":"2018-01-12T13:33:03Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Mon, Jan 8, 2018 at 11:38 PM, Lars Schneider\n wrote:\n>\n>> On 08 Jan 2018, at 23:07, Junio C Hamano wrote:\n>>\n>> SZEDER Gábor writes:\n>>\n>>> The reason why Travis CI does it this way and why it's a better\n>>> approach than ours lies in how unsuccessful build jobs are\n>>> categorized. ...\n>>> ...\n>>> This makes it easier, both for humans looking at the Travis CI web\n>>> interface and for automated tools querying the Travis CI API,...\n>>> ...\n>>> A verbose commit message for such a change... but I don't know why we\n>>> started with building Git in the 'before_script' phase.\n>>\n>> Thanks for writing it up clearly. TBH, I didn't even realize that\n>> there were meaningful distinctions between the two cases after\n>> seeing that sometimes our tests were failing and sometimes erroring\n>> ;-)\n>\n> I understand the reasons for the proposed patch. However, I did this\n> intentionally back then. Here is my reason:\n>\n> If `make` is successful, then I am not interested in its output.\n\nIf 'prove' is successful, then I'm not interested in its output ;)\n\n> Look at this run: https://travis-ci.org/szeder/git/jobs/324271623\n>\n> You have to scroll down 1,406 lines to get to the test result\n> output (this is usually the interesting part).\n\nThat's the just beginning of a looong list of executed test scripts in\nseemingly pseudo-random order. IMHO that's very rarely the interesting\npart; I, for one, am only interested in that list in exceptional cases,\ne.g. while tweaking the build dependencies or the 'prove --state=...'\noptions.\n\nThese are the really interesting parts of the build job's output, the\nparts that do matter most of the time:\n\n # compiler error\n https://travis-ci.org/git/git/jobs/325252417#L1766\n # which tests failed\n https://travis-ci.org/git/git/jobs/315658238#L2247\n # stray build artifacts\n https://travis-ci.org/szeder/git/jobs/323531220#L2236\n # (no example logs for erroring while installing dependencies, OSX\n # timeout, etc.)\n\nNote that these are all at the very end of the trace log, i.e. they are\neasily accessible by one or two keystrokes (depending on whether the\nkeyboard has a dedicated 'End' key or requires an Fn combo), a vigorous\ndrag of the scrollbar, or a click on the \"Scroll to end of log\" circle\nin the top right corner.\n\n> If this is a valid argument for you,\n\nI'm unconvinced :)\n\n> would it be an option to\n> pipe the verbose `make` output to a file and only print it in case\n> of error (we do something similar for the tests already).\n\nIt's risky, because the build process would be completely silent for the\nduration of building Git. Travis CI considers a build 'errored' if it\ndoesn't produce any output for 10 minutes. While building Git usually\ntakes much less time, transient slowdowns apparently do occur.\n\nGábor\n"},{"id":"336554","messageId":"20180113103255.GA31117@sigill.intra.peff.net","threadId":"47568","inReplyTo":"CAM0VKjnSzoc+E408ifKCg+qPTaGRNL3e3JVdRN573kdcBSzbHw@mail.gmail.com","subject":"Re: [PATCH] travis-ci: build Git during the 'script' phase","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-01-13T10:32:56Z","receivedAt":"2018-01-13T10:33:03Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jan 12, 2018 at 02:32:54PM +0100, SZEDER Gábor wrote:\n\n> That's the just beginning of a looong list of executed test scripts in\n> seemingly pseudo-random order. IMHO that's very rarely the interesting\n> part; I, for one, am only interested in that list in exceptional cases,\n> e.g. while tweaking the build dependencies or the 'prove --state=...'\n> options.\n\nAren't folds supposed to do this? I.e., record all the output but only\nshow it to the user if the command exited non-zero.\n\nAccording to:\n\n https://blog.travis-ci.com/2013-05-22-improving-build-visibility-log-folds\n\nthey auto-fold individual commands _except_ the ones in the script\nsection. Is there a way to manually mark folds in the output?\n\nHmph. I could not find an answer from travis, but googling seems to turn\nup that something like this would work:\n\ndiff --git a/ci/lib-travisci.sh b/ci/lib-travisci.sh\nindex 07f27c7270..8c830aa3c0 100755\n--- a/ci/lib-travisci.sh\n+++ b/ci/lib-travisci.sh\n@@ -77,6 +77,23 @@ check_unignored_build_artifacts ()\n \t}\n }\n \n+fold () {\n+\tprintf 'travis_fold:start:%s\\r' \"$1\"\n+}\n+\n+unfold () {\n+\tprintf 'travis_fold:end:%s\\r' \"$1\"\n+}\n+\n+fold_cmd () {\n+\tlocal name=$1; shift\n+\tfold \"$name\"\n+\t\"$@\"\n+\tlocal ret=$?\n+\tunfold \"$name\"\n+\treturn $ret\n+}\n+\n # Set 'exit on error' for all CI scripts to let the caller know that\n # something went wrong.\n # Set tracing executed commands, primarily setting environment variables\ndiff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh\nindex d3a094603f..12b2590230 100755\n--- a/ci/run-build-and-tests.sh\n+++ b/ci/run-build-and-tests.sh\n@@ -7,8 +7,8 @@\n \n ln -s $HOME/travis-cache/.prove t/.prove\n \n-make --jobs=2\n-make --quiet test\n+fold_cmd compile make --jobs=2\n+fold_cmd test make --quiet test\n \n check_unignored_build_artifacts\n \n\nI've queued a CI job to see if this actually works. :)\n\n-Peff\n"},{"id":"336555","messageId":"20180113105407.GA31825@sigill.intra.peff.net","threadId":"47568","inReplyTo":"20180113103255.GA31117@sigill.intra.peff.net","subject":"Re: [PATCH] travis-ci: build Git during the 'script' phase","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-01-13T10:54:07Z","receivedAt":"2018-01-13T10:54:14Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Jan 13, 2018 at 05:32:56AM -0500, Jeff King wrote:\n\n> According to:\n> \n> https://blog.travis-ci.com/2013-05-22-improving-build-visibility-log-folds\n> \n> they auto-fold individual commands _except_ the ones in the script\n> section. Is there a way to manually mark folds in the output?\n> \n> Hmph. I could not find an answer from travis, but googling seems to turn\n> up that something like this would work:\n> [...]\n> I've queued a CI job to see if this actually works. :)\n\nIndeed it does work:\n\n https://travis-ci.org/peff/git/jobs/328418291\n\nThe rest of the crufty output looks like \"set -x\" stuff. It might be\nworth being less aggressive there.\n\nI think there's also a similar feature to include timings for each fold,\nwhich might be worth pursuing.\n\n-Peff\n"},{"id":"336580","messageId":"CAM0VKj=QrDr9671uMGKSSZUczB-Soc5mmoijiBsx8t_WkQa6+w@mail.gmail.com","threadId":"47568","inReplyTo":"20180113103255.GA31117@sigill.intra.peff.net","subject":"Re: [PATCH] travis-ci: build Git during the 'script' phase","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2018-01-14T10:37:07Z","receivedAt":"2018-01-14T10:37:14Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Sat, Jan 13, 2018 at 11:32 AM, Jeff King wrote:\n> On Fri, Jan 12, 2018 at 02:32:54PM +0100, SZEDER Gábor wrote:\n>\n>> That's the just beginning of a looong list of executed test scripts in\n>> seemingly pseudo-random order. IMHO that's very rarely the interesting\n>> part; I, for one, am only interested in that list in exceptional cases,\n>> e.g. while tweaking the build dependencies or the 'prove --state=...'\n>> options.\n>\n> Aren't folds supposed to do this? I.e., record all the output but only\n> show it to the user if the command exited non-zero.\n>\n> According to:\n>\n> https://blog.travis-ci.com/2013-05-22-improving-build-visibility-log-folds\n>\n> they auto-fold individual commands _except_ the ones in the script\n> section. Is there a way to manually mark folds in the output?\n>\n> Hmph. I could not find an answer from travis, but googling seems to turn\n> up that something like this would work:\n\nOh. I did look for something like this in the Travis CI docs, found\nnothing and then didn't bother with Google. Rookie mistake, I know :)\n\nBut indeed, have a look at the raw trace log at:\n\n https://api.travis-ci.org/v3/job/328418291/log.txt\n\nIt starts with that \"travis_fold:start:...\" thing right away.\n\n> diff --git a/ci/lib-travisci.sh b/ci/lib-travisci.sh\n> index 07f27c7270..8c830aa3c0 100755\n> --- a/ci/lib-travisci.sh\n> +++ b/ci/lib-travisci.sh\n> @@ -77,6 +77,23 @@ check_unignored_build_artifacts ()\n> }\n> }\n>\n> +fold () {\n> + printf 'travis_fold:start:%s\\r' \"$1\"\n> +}\n> +\n> +unfold () {\n> + printf 'travis_fold:end:%s\\r' \"$1\"\n> +}\n> +\n> +fold_cmd () {\n> + local name=$1; shift\n> + fold \"$name\"\n> + \"$@\"\n> + local ret=$?\n> + unfold \"$name\"\n> + return $ret\n> +}\n\nWe don't have to fiddle with the return value, because we run (almost\nall of) our build scripts with 'set -e', i.e. if the command fails then\nthe script will exit immediately.\n\n> +\n> # Set 'exit on error' for all CI scripts to let the caller know that\n> # something went wrong.\n> # Set tracing executed commands, primarily setting environment variables\n> diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh\n> index d3a094603f..12b2590230 100755\n> --- a/ci/run-build-and-tests.sh\n> +++ b/ci/run-build-and-tests.sh\n> @@ -7,8 +7,8 @@\n>\n> ln -s $HOME/travis-cache/.prove t/.prove\n>\n> -make --jobs=2\n> -make --quiet test\n> +fold_cmd compile make --jobs=2\n> +fold_cmd test make --quiet test\n>\n> check_unignored_build_artifacts\n>\n>\n> I've queued a CI job to see if this actually works. :)\n>\n> -Peff\n"},{"id":"336581","messageId":"CAM0VKjkmEThnM7KdQ=SJFGK1E_zdjsCFnFas7fsRG97aQmS52g@mail.gmail.com","threadId":"47568","inReplyTo":"20180113105407.GA31825@sigill.intra.peff.net","subject":"Re: [PATCH] travis-ci: build Git during the 'script' phase","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2018-01-14T10:43:05Z","receivedAt":"2018-01-14T10:43:10Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Sat, Jan 13, 2018 at 11:54 AM, Jeff King wrote:\n> I think there's also a similar feature to include timings for each fold,\n> which might be worth pursuing.\n\nIf you look for 'travis_time' in the raw log, you'll find lines like\nthese:\n\n travis_time:start:01ccbe40\n $ some-command\n ... and its output ...\n travis_time:end:01ccbe40:start=1515840453305552968,finish=1515840471960386859,duration=18654833891\n\nSo it seems doable, but we'll have to do the timekeeping ourselves.\nRunning 'time $cmd' is much easier, but that time won't be displayed\nnext to the folds, of course.\nDo we really care that much?\n\n\nGábor\n"},{"id":"336582","messageId":"20180114110734.GA13643@sigill.intra.peff.net","threadId":"47568","inReplyTo":"CAM0VKj=QrDr9671uMGKSSZUczB-Soc5mmoijiBsx8t_WkQa6+w@mail.gmail.com","subject":"Re: [PATCH] travis-ci: build Git during the 'script' phase","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-01-14T11:07:34Z","receivedAt":"2018-01-14T11:07:41Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Jan 14, 2018 at 11:37:07AM +0100, SZEDER Gábor wrote:\n\n> > +fold_cmd () {\n> > + local name=$1; shift\n> > + fold \"$name\"\n> > + \"$@\"\n> > + local ret=$?\n> > + unfold \"$name\"\n> > + return $ret\n> > +}\n> \n> We don't have to fiddle with the return value, because we run (almost\n> all of) our build scripts with 'set -e', i.e. if the command fails then\n> the script will exit immediately.\n\nYeah, that's probably enough for our simple scripts, though I have been\nbit by \"set -e\" vagaries before (e.g., calling the function inside a\nconditional block).\n\n-Peff\n"},{"id":"336583","messageId":"20180114111048.GB13643@sigill.intra.peff.net","threadId":"47568","inReplyTo":"CAM0VKjkmEThnM7KdQ=SJFGK1E_zdjsCFnFas7fsRG97aQmS52g@mail.gmail.com","subject":"Re: [PATCH] travis-ci: build Git during the 'script' phase","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-01-14T11:10:48Z","receivedAt":"2018-01-14T11:10:55Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Jan 14, 2018 at 11:43:05AM +0100, SZEDER Gábor wrote:\n\n> On Sat, Jan 13, 2018 at 11:54 AM, Jeff King wrote:\n> > I think there's also a similar feature to include timings for each fold,\n> > which might be worth pursuing.\n> \n> If you look for 'travis_time' in the raw log, you'll find lines like\n> these:\n> \n> travis_time:start:01ccbe40\n> $ some-command\n> ... and its output ...\n> travis_time:end:01ccbe40:start=1515840453305552968,finish=1515840471960386859,duration=18654833891\n> \n> So it seems doable, but we'll have to do the timekeeping ourselves.\n> Running 'time $cmd' is much easier, but that time won't be displayed\n> next to the folds, of course.\n> Do we really care that much?\n\nI don't care that much (and I wasn't actually planning to push the fold\nstuff into a patch, but would instead leave it to you people who were\nalready working on improving the ci script output ;) ).\n\nApparently there are exportable bash functions for all of this:\n\n http://www.garbers.co.za/2017/11/01/code-folding-and-timing-in-travis-ci/\n\nbut they're not part of the official API. So relying on them may be even\nmore questionable than relying on the travis_fold syntax.\n\n-Peff\n"}]}