{"thread":{"id":"40532","subject":"[PATCH v3 1/3] Add Travis CI support","startedAt":"2015-10-11T17:54:59Z","lastAt":"2015-10-15T17:14:15Z","messageCount":29,"participants":["larsxschneider@gmail.com","Eric Sunshine","Luke Diamand","Sebastian Schuberth","Junio C Hamano","Lars Schneider","Matthieu Moy","Jean-Noël Avila","Johannes Schindelin"],"isPatch":true,"patchVersion":3,"patchTotal":3},"messages":[{"id":"271422","messageId":"1444586102-82557-1-git-send-email-larsxschneider@gmail.com","threadId":"40532","inReplyTo":null,"subject":"[PATCH v3 0/3] Add Travis CI support","fromName":"","fromEmail":"larsxschneider@gmail.com","sentAt":"2015-10-11T17:54:59Z","receivedAt":"2015-10-11T17:54:59Z","isPatch":true,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"From: Lars Schneider \n\ndiff to v2:\n* fix commit message to express what systems the Travis CI's infrastructure\n \"currently\" uses (thanks Dscho)\n* use `case` instead `if` syntax for OS detection (thanks Dscho)\n* remove unnessary DARWIN flag (thanks Junio)\n* use flag `case_insensitive_fs` to disable t9819-git-p4-case-folding based on\n the currently used filesytem (thanks Junio)\n* replace `stats` call in t9815-git-p4-submit-fail with `ls` to improve\n portability (thanks Junio, Torsten, and Pete)\n* use Travis lifecycle properly to make output foldable in Travis (see\n little triangle on the left of the output on the Travis website)\n* set git test option \"--quite\" and run make with option \"--quite\" to reduce\n log output noise\n\nThanks,\nLars\n\nLars Schneider (3):\n Add Travis CI support\n git-p4: Improve test case portability for t9815 git-p4-submit-fail\n git-p4: Skip t9819 test case on case insensitive file systems\n\n .travis.yml | 46 ++++++++++++++++++++++++++++++++++++++++++\n t/t9815-git-p4-submit-fail.sh | 7 ++-----\n t/t9819-git-p4-case-folding.sh | 6 ++++++\n 3 files changed, 54 insertions(+), 5 deletions(-)\n create mode 100644 .travis.yml\n\n--\n2.5.1\n"},{"id":"271421","messageId":"1444586102-82557-2-git-send-email-larsxschneider@gmail.com","threadId":"40532","inReplyTo":"1444586102-82557-1-git-send-email-larsxschneider@gmail.com","subject":"[PATCH v3 1/3] Add Travis CI support","fromName":"","fromEmail":"larsxschneider@gmail.com","sentAt":"2015-10-11T17:55:00Z","receivedAt":"2015-10-11T17:55:00Z","isPatch":true,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"From: Lars Schneider \n\nThe tests are currently executed on \"Ubuntu 12.04 LTS Server Edition\n64 bit\" and on \"OS X Mavericks\" using gcc and clang.\n\nPerforce and Git-LFS are installed and therefore available for the\nrespective tests.\n\nSigned-off-by: Lars Schneider \n---\n .travis.yml | 46 ++++++++++++++++++++++++++++++++++++++++++++++\n 1 file changed, 46 insertions(+)\n create mode 100644 .travis.yml\n\ndiff --git a/.travis.yml b/.travis.yml\nnew file mode 100644\nindex 0000000..25a7079\n--- /dev/null\n+++ b/.travis.yml\n@@ -0,0 +1,46 @@\n+language: c\n+\n+os:\n+ - linux\n+ - osx\n+\n+compiler:\n+ - clang\n+ - gcc\n+\n+before_install:\n+ - >\n+ export GIT_TEST_OPTS=\" --quiet\";\n+ case \"${TRAVIS_OS_NAME:-linux}\" in\n+ linux)\n+ wget -q https://package.perforce.com/perforce.pubkey -O - \\\n+ | sudo apt-key add -\n+ echo 'deb http://package.perforce.com/apt/ubuntu precise release' \\\n+ | sudo tee -a /etc/apt/sources.list\n+ wget -q https://packagecloud.io/gpg.key -O - | sudo apt-key add -\n+ echo 'deb https://packagecloud.io/github/git-lfs/debian/ jessie main' \\\n+ | sudo tee -a /etc/apt/sources.list\n+ sudo apt-get update -qq\n+ sudo apt-get install -y apt-transport-https\n+ sudo apt-get install perforce-server git-lfs\n+ ;;\n+ osx)\n+ brew_force_set_latest_binary_hash () {\n+ FORUMULA=$1\n+ SHA=$(brew fetch --force $FORUMULA 2>&1 | grep ^SHA256: | cut -d ' ' -f 2)\n+ sed -E -i.bak \"s/sha256 \\\"[0-9a-f]{64}\\\"/sha256 \\\"$SHA\\\"/g\" \\\n+ /usr/local/Library/Taps/homebrew/homebrew-binary/$FORUMULA.rb\n+ }\n+ brew update\n+ brew tap homebrew/binary\n+ brew_force_set_latest_binary_hash perforce\n+ brew_force_set_latest_binary_hash perforce-server\n+ brew install git-lfs perforce-server perforce\n+ ;;\n+ esac\n+\n+install: make configure && ./configure\n+\n+before_script: make\n+\n+script: make --quiet test\n-- \n2.5.1\n"},{"id":"271424","messageId":"1444586102-82557-3-git-send-email-larsxschneider@gmail.com","threadId":"40532","inReplyTo":"1444586102-82557-1-git-send-email-larsxschneider@gmail.com","subject":"[PATCH v3 2/3] git-p4: Improve test case portability for t9815 git-p4-submit-fail","fromName":"","fromEmail":"larsxschneider@gmail.com","sentAt":"2015-10-11T17:55:01Z","receivedAt":"2015-10-11T17:55:01Z","isPatch":true,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"From: Lars Schneider \n\nReplace the stats command with the ls command to check file mode bits.\nThe stats command is not available on Windows and has different\ncommand line options on OS X.\n\nSigned-off-by: Lars Schneider \n---\n t/t9815-git-p4-submit-fail.sh | 7 ++-----\n 1 file changed, 2 insertions(+), 5 deletions(-)\n\ndiff --git a/t/t9815-git-p4-submit-fail.sh b/t/t9815-git-p4-submit-fail.sh\nindex 4cff6a7..37b42d0 100755\n--- a/t/t9815-git-p4-submit-fail.sh\n+++ b/t/t9815-git-p4-submit-fail.sh\n@@ -417,11 +417,8 @@ test_expect_success 'cleanup chmod after submit cancel' '\n \t\t! p4 fstat -T action text &&\n \t\ttest_path_is_file text+x &&\n \t\t! p4 fstat -T action text+x &&\n-\t\tif test_have_prereq !CYGWIN\n-\t\tthen\n-\t\t\tstat --format=%A text | egrep ^-r-- &&\n-\t\t\tstat --format=%A text+x | egrep ^-r-x\n-\t\tfi\n+\t\tls -l text | egrep ^-r-- &&\n+\t\tls -l text+x | egrep ^-r-x\n \t)\n '\n \n-- \n2.5.1\n"},{"id":"271423","messageId":"1444586102-82557-4-git-send-email-larsxschneider@gmail.com","threadId":"40532","inReplyTo":"1444586102-82557-1-git-send-email-larsxschneider@gmail.com","subject":"[PATCH v3 3/3] git-p4: Skip t9819 test case on case insensitive file systems","fromName":"","fromEmail":"larsxschneider@gmail.com","sentAt":"2015-10-11T17:55:02Z","receivedAt":"2015-10-11T17:55:02Z","isPatch":true,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"From: Lars Schneider \n\nWindows and OS X file systems are case insensitive by default.\nConsequently the \"git-p4-case-folding\" test case does not apply to\nthem.\n\nSigned-off-by: Lars Schneider \n---\n t/t9819-git-p4-case-folding.sh | 6 ++++++\n 1 file changed, 6 insertions(+)\n\ndiff --git a/t/t9819-git-p4-case-folding.sh b/t/t9819-git-p4-case-folding.sh\nindex 78f1d0f..d808c00 100755\n--- a/t/t9819-git-p4-case-folding.sh\n+++ b/t/t9819-git-p4-case-folding.sh\n@@ -4,6 +4,12 @@ test_description='interaction with P4 case-folding'\n \n . ./lib-git-p4.sh\n \n+if test_have_prereq CASE_INSENSITIVE_FS\n+then\n+\tskip_all='skipping P4 case-folding tests; case insensitive file system detected'\n+\ttest_done\n+fi\n+\n test_expect_success 'start p4d with case folding enabled' '\n \tstart_p4d -C1\n '\n-- \n2.5.1\n"},{"id":"271432","messageId":"CAPig+cQ4Gd6aNQdrdD7ZEJW2Mn=pJujkqje0-htJpJYz8LVbhQ@mail.gmail.com","threadId":"40532","inReplyTo":"1444586102-82557-2-git-send-email-larsxschneider@gmail.com","subject":"Re: [PATCH v3 1/3] Add Travis CI support","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2015-10-11T20:40:59Z","receivedAt":"2015-10-11T20:40:59Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Sun, Oct 11, 2015 at 1:55 PM, wrote:\n> From: Lars Schneider \n>\n> The tests are currently executed on \"Ubuntu 12.04 LTS Server Edition\n> 64 bit\" and on \"OS X Mavericks\" using gcc and clang.\n>\n> Perforce and Git-LFS are installed and therefore available for the\n> respective tests.\n>\n> Signed-off-by: Lars Schneider \n> ---\n> diff --git a/.travis.yml b/.travis.yml\n> new file mode 100644\n> index 0000000..25a7079\n> --- /dev/null\n> +++ b/.travis.yml\n> @@ -0,0 +1,46 @@\n> +language: c\n> +\n> +os:\n> + - linux\n> + - osx\n> +\n> +compiler:\n> + - clang\n> + - gcc\n> +\n> +before_install:\n> + - >\n> + export GIT_TEST_OPTS=\" --quiet\";\n> + case \"${TRAVIS_OS_NAME:-linux}\" in\n> + linux)\n> + wget -q https://package.perforce.com/perforce.pubkey -O - \\\n> + | sudo apt-key add -\n> + echo 'deb http://package.perforce.com/apt/ubuntu precise release' \\\n> + | sudo tee -a /etc/apt/sources.list\n> + wget -q https://packagecloud.io/gpg.key -O - | sudo apt-key add -\n> + echo 'deb https://packagecloud.io/github/git-lfs/debian/ jessie main' \\\n> + | sudo tee -a /etc/apt/sources.list\n> + sudo apt-get update -qq\n> + sudo apt-get install -y apt-transport-https\n> + sudo apt-get install perforce-server git-lfs\n> + ;;\n> + osx)\n> + brew_force_set_latest_binary_hash () {\n> + FORUMULA=$1\n\nIs this spelling intentional or is it a misspelling of \"formula\"?\n\n> + SHA=$(brew fetch --force $FORUMULA 2>&1 | grep ^SHA256: | cut -d ' ' -f 2)\n> + sed -E -i.bak \"s/sha256 \\\"[0-9a-f]{64}\\\"/sha256 \\\"$SHA\\\"/g\" \\\n> + /usr/local/Library/Taps/homebrew/homebrew-binary/$FORUMULA.rb\n> + }\n> + brew update\n> + brew tap homebrew/binary\n> + brew_force_set_latest_binary_hash perforce\n> + brew_force_set_latest_binary_hash perforce-server\n> + brew install git-lfs perforce-server perforce\n> + ;;\n> + esac\n> +\n> +install: make configure && ./configure\n> +\n> +before_script: make\n> +\n> +script: make --quiet test\n> --\n> 2.5.1\n"},{"id":"271436","messageId":"CAE5ih79M9guQsjs34XmyE6sxExa6a6KkgdYEHOyeBCv57-4-QA@mail.gmail.com","threadId":"40532","inReplyTo":"1444586102-82557-4-git-send-email-larsxschneider@gmail.com","subject":"Re: [PATCH v3 3/3] git-p4: Skip t9819 test case on case insensitive file systems","fromName":"Luke Diamand","fromEmail":"luke@diamand.org","sentAt":"2015-10-12T06:47:05Z","receivedAt":"2015-10-12T06:47:05Z","isPatch":true,"sender":{"key":"luke@diamand.org","avatar":"https://avatars.githubusercontent.com/u/5330967?v=4"},"body":"Looks good to me, Ack.\n\nOn 11 October 2015 at 18:55, wrote:\n> From: Lars Schneider \n>\n> Windows and OS X file systems are case insensitive by default.\n> Consequently the \"git-p4-case-folding\" test case does not apply to\n> them.\n>\n> Signed-off-by: Lars Schneider \n> ---\n> t/t9819-git-p4-case-folding.sh | 6 ++++++\n> 1 file changed, 6 insertions(+)\n>\n> diff --git a/t/t9819-git-p4-case-folding.sh b/t/t9819-git-p4-case-folding.sh\n> index 78f1d0f..d808c00 100755\n> --- a/t/t9819-git-p4-case-folding.sh\n> +++ b/t/t9819-git-p4-case-folding.sh\n> @@ -4,6 +4,12 @@ test_description='interaction with P4 case-folding'\n>\n> . ./lib-git-p4.sh\n>\n> +if test_have_prereq CASE_INSENSITIVE_FS\n> +then\n> + skip_all='skipping P4 case-folding tests; case insensitive file system detected'\n> + test_done\n> +fi\n> +\n> test_expect_success 'start p4d with case folding enabled' '\n> start_p4d -C1\n> '\n> --\n> 2.5.1\n>\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"271439","messageId":"561B69AE.8050403@gmail.com","threadId":"40532","inReplyTo":"1444586102-82557-2-git-send-email-larsxschneider@gmail.com","subject":"Re: [PATCH v3 1/3] Add Travis CI support","fromName":"Sebastian Schuberth","fromEmail":"sschuberth@gmail.com","sentAt":"2015-10-12T08:05:02Z","receivedAt":"2015-10-12T08:05:02Z","isPatch":true,"sender":{"key":"sschuberth@gmail.com","avatar":"https://avatars.githubusercontent.com/u/349154?v=4"},"body":"On 10/11/2015 19:55, larsxschneider@gmail.com wrote:\n\n> + sudo apt-get update -qq\n> + sudo apt-get install -y apt-transport-https\n> + sudo apt-get install perforce-server git-lfs\n\nWhy no \"-y\" also in this line, or append these to the previous line?\n\nOr maybe even better, like [1] does, also use \"--qq\" (which implies \n\"-y\") for \"apt-get install\"?\n\n> +install: make configure && ./configure\n> +\n> +before_script: make\n> +\n> +script: make --quiet test\n\nSemantically, it does not seem correct to me that configuarion goes to \nthe install step. As \"make test\" will build git anyway, I'd instead \npropose to get rid of \"install\" and just say:\n\nbefore_script: make configure && ./configure\n\nscript: make --quiet test\n\n[1] https://github.com/git/git/pull/154/files\n\nRegards,\nSebastian\n"},{"id":"271451","messageId":"xmqq37xgnkh0.fsf@gitster.mtv.corp.google.com","threadId":"40532","inReplyTo":"561B69AE.8050403@gmail.com","subject":"Re: [PATCH v3 1/3] Add Travis CI support","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-10-12T16:02:35Z","receivedAt":"2015-10-12T16:02:35Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sebastian Schuberth writes:\n\n> Semantically, it does not seem correct to me that configuarion goes to\n> the install step. As \"make test\" will build git anyway, I'd instead\n> propose to get rid of \"install\" and just say:\n>\n> before_script: make configure && ./configure\n>\n> script: make --quiet test\n\nVery good point. Do we even need to do anything in the \"install\"\ntarget? We aim to be able to testable without any installed Git,\nand not running \"make install\" at all, ever, would be one way to\nmake sure that works.\n\nThis is a slightly related tangent, but we saw a few build issues\nreported recently on customized configurations like NO_PTHREAD. If\nwe are to start using automated tests, I wonder if we want to build\n(and optionally test) with various combinations of the customization\noptions (e.g. NO_CURL, NO_OPENSSL, NO_MMAP, NO_IPV6, NO_PERL etc.)\n\nThanks.\n"},{"id":"271454","messageId":"xmqqpp0km5o5.fsf@gitster.mtv.corp.google.com","threadId":"40532","inReplyTo":"1444586102-82557-1-git-send-email-larsxschneider@gmail.com","subject":"Re: [PATCH v3 0/3] Add Travis CI support","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-10-12T16:07:38Z","receivedAt":"2015-10-12T16:07:38Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"larsxschneider@gmail.com writes:\n\n> Lars Schneider (3):\n> Add Travis CI support\n> git-p4: Improve test case portability for t9815 git-p4-submit-fail\n> git-p4: Skip t9819 test case on case insensitive file systems\n\nCan you make this two separate series? It seems Luke is happy with\nthe p4 bits and I think it makes sense to have it as a separate\nseries and apply sooner, while those who are interested in and well\nversed in Travis to help polishing the first one.\n"},{"id":"271455","messageId":"xmqqoag4m5nn.fsf@gitster.mtv.corp.google.com","threadId":"40532","inReplyTo":"1444586102-82557-1-git-send-email-larsxschneider@gmail.com","subject":"Re: [PATCH v3 0/3] Add Travis CI support","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-10-12T16:07:56Z","receivedAt":"2015-10-12T16:07:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"larsxschneider@gmail.com writes:\n\n> Lars Schneider (3):\n> Add Travis CI support\n> git-p4: Improve test case portability for t9815 git-p4-submit-fail\n> git-p4: Skip t9819 test case on case insensitive file systems\n\nCan you split this into two separate series?\n\nIt seems Luke is happy with the p4 bits and I think it makes sense\nto have it as a separate series and apply sooner, while those who\nare interested in and well versed in Travis to help polishing the\nfirst one.\n\nThanks.\n"},{"id":"271456","messageId":"CF49BE6B-38E7-4552-B9C7-B7965E8A7881@gmail.com","threadId":"40532","inReplyTo":"CAPig+cQ4Gd6aNQdrdD7ZEJW2Mn=pJujkqje0-htJpJYz8LVbhQ@mail.gmail.com","subject":"Re: [PATCH v3 1/3] Add Travis CI support","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2015-10-12T16:46:33Z","receivedAt":"2015-10-12T16:46:33Z","isPatch":true,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\n>> + brew_force_set_latest_binary_hash () {\n>> + FORUMULA=$1\n> \n> Is this spelling intentional or is it a misspelling of \"formula\"?\n\nThis is a misspelling. I will fix it.\n\nThanks,\nLars\n"},{"id":"271460","messageId":"BF182294-B896-4C2D-B371-74036BC522A2@gmail.com","threadId":"40532","inReplyTo":"561B69AE.8050403@gmail.com","subject":"Re: [PATCH v3 1/3] Add Travis CI support","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2015-10-12T17:12:51Z","receivedAt":"2015-10-12T17:12:51Z","isPatch":true,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\nOn 12 Oct 2015, at 01:05, Sebastian Schuberth wrote:\n\n> On 10/11/2015 19:55, larsxschneider@gmail.com wrote:\n> \n>> + sudo apt-get update -qq\n>> + sudo apt-get install -y apt-transport-https\n>> + sudo apt-get install perforce-server git-lfs\n> \n> Why no \"-y\" also in this line, or append these to the previous line?\n> \n> Or maybe even better, like [1] does, also use \"--qq\" (which implies \"-y\") for \"apt-get install\"?\nAgreed!\n\n> \n>> +install: make configure && ./configure\n>> +\n>> +before_script: make\n>> +\n>> +script: make --quiet test\n> \n> Semantically, it does not seem correct to me that configuarion goes to the install step. As \"make test\" will build git anyway, I'd instead propose to get rid of \"install\" and just say:\n> \n> before_script: make configure && ./configure\n> \n> script: make --quiet test\n\nI understand your point. I did this to make the \"make\" logs easily accessible (no option \"--quite\"). By default Travis CI automatically collapses the logs from all stages prior to the \"script\" stage. You can uncollapse these logs by clicking on the little triangle on the left border of the log. Therefore the \"make\" logs are available without noise.\n\nDo you see value in \"make\" logs? \n\nIf yes then we could also do:\nbefore_script: make configure && ./configure && make\n\nIf no then I will take your suggestion.\n\nThanks,\nLars"},{"id":"271467","messageId":"CAHGBnuMU6d3rqW6sa=u+mE-95zRJZvopJVdLQAUi=-cc+xW86A@mail.gmail.com","threadId":"40532","inReplyTo":"xmqq37xgnkh0.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v3 1/3] Add Travis CI support","fromName":"Sebastian Schuberth","fromEmail":"sschuberth@gmail.com","sentAt":"2015-10-12T18:42:17Z","receivedAt":"2015-10-12T18:42:17Z","isPatch":true,"sender":{"key":"sschuberth@gmail.com","avatar":"https://avatars.githubusercontent.com/u/349154?v=4"},"body":"On Mon, Oct 12, 2015 at 6:02 PM, Junio C Hamano wrote:\n\n>> Semantically, it does not seem correct to me that configuarion goes to\n>> the install step. As \"make test\" will build git anyway, I'd instead\n>> propose to get rid of \"install\" and just say:\n>>\n>> before_script: make configure && ./configure\n>>\n>> script: make --quiet test\n>\n> Very good point. Do we even need to do anything in the \"install\"\n> target? We aim to be able to testable without any installed Git,\n> and not running \"make install\" at all, ever, would be one way to\n> make sure that works.\n\nNote that Travis' \"install\" step is about installing dependencies for\nthe application to build [1], not for installing the built application\n(i.e. what \"make install\" does). In any case, I still think\nconfiguring the application to built in this step is wrong.\n\n> we are to start using automated tests, I wonder if we want to build\n> (and optionally test) with various combinations of the customization\n> options (e.g. NO_CURL, NO_OPENSSL, NO_MMAP, NO_IPV6, NO_PERL etc.)\n\nI like that idea, but I think we should save that for a future\nimprovement to .travis.yml.\n\n[1] http://docs.travis-ci.com/user/installing-dependencies/\n\n-- \nSebastian Schuberth\n"},{"id":"271481","messageId":"CAHGBnuOqVPHAhfN6qtt=VDODW9h+A1xMEnzaZfD61DCNyj_YOg@mail.gmail.com","threadId":"40532","inReplyTo":"BF182294-B896-4C2D-B371-74036BC522A2@gmail.com","subject":"Re: [PATCH v3 1/3] Add Travis CI support","fromName":"Sebastian Schuberth","fromEmail":"sschuberth@gmail.com","sentAt":"2015-10-12T19:37:16Z","receivedAt":"2015-10-12T19:37:16Z","isPatch":true,"sender":{"key":"sschuberth@gmail.com","avatar":"https://avatars.githubusercontent.com/u/349154?v=4"},"body":"On Mon, Oct 12, 2015 at 7:12 PM, Lars Schneider\n wrote:\n\n>>> +install: make configure && ./configure\n>>> +\n>>> +before_script: make\n>>> +\n>>> +script: make --quiet test\n>>\n>> Semantically, it does not seem correct to me that configuarion goes to the install step. As \"make test\" will build git anyway, I'd instead propose to get rid of \"install\" and just say:\n>>\n>> before_script: make configure && ./configure\n>>\n>> script: make --quiet test\n>\n> I understand your point. I did this to make the \"make\" logs easily accessible (no option \"--quite\"). By default Travis CI automatically collapses the logs from all stages prior to the \"script\" stage. You can uncollapse these logs by clicking on the little triangle on the left border of the log. Therefore the \"make\" logs are available without noise.\n\nTo make this more clear, I guess what you're referring to is the\nvisual difference between [1] and [2], correct?\n\n> Do you see value in \"make\" logs?\n>\n> If yes then we could also do:\n> before_script: make configure && ./configure && make\n\nReading through Travis' docs [3] again, \"before_script\" is documented\nto \"return a non-zero exit code, the build is errored and stops\nimmediately\", while \"script\" is documented as \"returns a non-zero exit\ncode, the build is failed, but continues to run before being marked as\nfailed\". As it does not make much sense to continue the build or even\nstart testing if the build failed, maybe it's indeed best to do:\n\nbefore_script: make configure && ./configure && make\n\nscript: make --quiet test\n\n[1] https://travis-ci.org/larsxschneider/git/jobs/84805733\n[2] https://travis-ci.org/larsxschneider/git/jobs/84955658\n[3] http://docs.travis-ci.com/user/customizing-the-build/\n\n-- \nSebastian Schuberth\n"},{"id":"271482","messageId":"B85D5671-9F8C-452E-87B9-EB4DE3C85955@gmail.com","threadId":"40532","inReplyTo":"xmqq37xgnkh0.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v3 1/3] Add Travis CI support","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2015-10-12T19:40:21Z","receivedAt":"2015-10-12T19:40:21Z","isPatch":true,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\nOn 12 Oct 2015, at 09:02, Junio C Hamano wrote:\n\n> Sebastian Schuberth writes:\n> \n>> Semantically, it does not seem correct to me that configuarion goes to\n>> the install step. As \"make test\" will build git anyway, I'd instead\n>> propose to get rid of \"install\" and just say:\n>> \n>> before_script: make configure && ./configure\n>> \n>> script: make --quiet test\n> \n> Very good point. Do we even need to do anything in the \"install\"\n> target? We aim to be able to testable without any installed Git,\n> and not running \"make install\" at all, ever, would be one way to\n> make sure that works.\nThe Travis CI \"install\" stage is independent of \"make install\". AFAIK you can use the Travis lifecycle stages pretty much as you want. However, I agree we should not use the \"install\" stage to avoid confusion.\n\n\n> This is a slightly related tangent, but we saw a few build issues\n> reported recently on customized configurations like NO_PTHREAD. If\n> we are to start using automated tests, I wonder if we want to build\n> (and optionally test) with various combinations of the customization\n> options (e.g. NO_CURL, NO_OPENSSL, NO_MMAP, NO_IPV6, NO_PERL etc.)\nThis easy to do. However, the more we environment settings we define the longer the build runs. I created a test matrix that runs the following combinations:\n{Linux | OSX} * {gcc | clang} * {Default, NO_PTHREAD, NO_CURL, NO_OPENSSL, NO_MMAP, NO_IPV6, NO_PERL}\n\nThese result in 28 (= 2*2*7) combinations. I created a build without the \"Default\" environment (=24 combination) here:\nhttps://travis-ci.org/larsxschneider/git/builds/84978673\n\nShould I add them them to the Travis CI patch?\n\nThanks,\nLars\n"},{"id":"271483","messageId":"61B448FB-DB61-42B6-ACDF-181F76169061@gmail.com","threadId":"40532","inReplyTo":"CAHGBnuOqVPHAhfN6qtt=VDODW9h+A1xMEnzaZfD61DCNyj_YOg@mail.gmail.com","subject":"Re: [PATCH v3 1/3] Add Travis CI support","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2015-10-12T19:43:29Z","receivedAt":"2015-10-12T19:43:29Z","isPatch":true,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\nOn 12 Oct 2015, at 12:37, Sebastian Schuberth wrote:\n\n> On Mon, Oct 12, 2015 at 7:12 PM, Lars Schneider\n> wrote:\n> \n>>>> +install: make configure && ./configure\n>>>> +\n>>>> +before_script: make\n>>>> +\n>>>> +script: make --quiet test\n>>> \n>>> Semantically, it does not seem correct to me that configuarion goes to the install step. As \"make test\" will build git anyway, I'd instead propose to get rid of \"install\" and just say:\n>>> \n>>> before_script: make configure && ./configure\n>>> \n>>> script: make --quiet test\n>> \n>> I understand your point. I did this to make the \"make\" logs easily accessible (no option \"--quite\"). By default Travis CI automatically collapses the logs from all stages prior to the \"script\" stage. You can uncollapse these logs by clicking on the little triangle on the left border of the log. Therefore the \"make\" logs are available without noise.\n> \n> To make this more clear, I guess what you're referring to is the\n> visual difference between [1] and [2], correct?\ncorrect!\n\n> \n>> Do you see value in \"make\" logs?\n>> \n>> If yes then we could also do:\n>> before_script: make configure && ./configure && make\n> \n> Reading through Travis' docs [3] again, \"before_script\" is documented\n> to \"return a non-zero exit code, the build is errored and stops\n> immediately\", while \"script\" is documented as \"returns a non-zero exit\n> code, the build is failed, but continues to run before being marked as\n> failed\". As it does not make much sense to continue the build or even\n> start testing if the build failed, maybe it's indeed best to do:\n> \n> before_script: make configure && ./configure && make\n> \n> script: make --quiet test\n\nOk, then I will make it so :-)\n\nThanks,\nLars"},{"id":"271485","messageId":"CAHGBnuNxZY9KEo43c31EEm-mzS3wmw-OLkmYa5jYmCJ64a655A@mail.gmail.com","threadId":"40532","inReplyTo":"B85D5671-9F8C-452E-87B9-EB4DE3C85955@gmail.com","subject":"Re: [PATCH v3 1/3] Add Travis CI support","fromName":"Sebastian Schuberth","fromEmail":"sschuberth@gmail.com","sentAt":"2015-10-12T19:48:44Z","receivedAt":"2015-10-12T19:48:44Z","isPatch":true,"sender":{"key":"sschuberth@gmail.com","avatar":"https://avatars.githubusercontent.com/u/349154?v=4"},"body":"On Mon, Oct 12, 2015 at 9:40 PM, Lars Schneider\n wrote:\n\n>> This is a slightly related tangent, but we saw a few build issues\n>> reported recently on customized configurations like NO_PTHREAD. If\n>> we are to start using automated tests, I wonder if we want to build\n>> (and optionally test) with various combinations of the customization\n>> options (e.g. NO_CURL, NO_OPENSSL, NO_MMAP, NO_IPV6, NO_PERL etc.)\n> This easy to do. However, the more we environment settings we define the longer the build runs. I created a test matrix that runs the following combinations:\n> {Linux | OSX} * {gcc | clang} * {Default, NO_PTHREAD, NO_CURL, NO_OPENSSL, NO_MMAP, NO_IPV6, NO_PERL}\n>\n> These result in 28 (= 2*2*7) combinations. I created a build without the \"Default\" environment (=24 combination) here:\n> https://travis-ci.org/larsxschneider/git/builds/84978673\n>\n> Should I add them them to the Travis CI patch?\n\nI'd say it depends on how long such a matrix build would take in\naverage. Personally, I'd prefer to not wait more than, say, 30 minutes\nfor testing a PR. From your Travis build history it looks to me as if\nwe already exceed that limit many fold, so I'd prefer to not use\nmatrix builds unless we find ways to speed up the build in general,\nfor example by using ccache [1].\n\n[1] http://docs.travis-ci.com/user/caching/#ccache-cache\n\n-- \nSebastian Schuberth\n"},{"id":"271486","messageId":"CAHGBnuN+sBptYQo2T03-Ja1E_6Q3SdT7dBEVPOQXupvDU3Ot1Q@mail.gmail.com","threadId":"40532","inReplyTo":"61B448FB-DB61-42B6-ACDF-181F76169061@gmail.com","subject":"Re: [PATCH v3 1/3] Add Travis CI support","fromName":"Sebastian Schuberth","fromEmail":"sschuberth@gmail.com","sentAt":"2015-10-12T19:53:32Z","receivedAt":"2015-10-12T19:53:32Z","isPatch":true,"sender":{"key":"sschuberth@gmail.com","avatar":"https://avatars.githubusercontent.com/u/349154?v=4"},"body":"On Mon, Oct 12, 2015 at 9:43 PM, Lars Schneider\n wrote:\n\n>> Reading through Travis' docs [3] again, \"before_script\" is documented\n>> to \"return a non-zero exit code, the build is errored and stops\n>> immediately\", while \"script\" is documented as \"returns a non-zero exit\n>> code, the build is failed, but continues to run before being marked as\n>> failed\". As it does not make much sense to continue the build or even\n>> start testing if the build failed, maybe it's indeed best to do:\n>>\n>> before_script: make configure && ./configure && make\n>>\n>> script: make --quiet test\n>\n> Ok, then I will make it so :-)\n\nAlso, this has the added benefit of being quickly able to see how much\ntime building vs testing took. As these two are the big blocks, we'd\nwant to optimize both steps for time, and it's easier to see what we\ngain e.g. from a possible build-time improvement if these steps are\nlisted individually in the Travis log.\n\n-- \nSebastian Schuberth\n"},{"id":"271488","messageId":"vpq7fmryhiy.fsf@grenoble-inp.fr","threadId":"40532","inReplyTo":"B85D5671-9F8C-452E-87B9-EB4DE3C85955@gmail.com","subject":"Re: [PATCH v3 1/3] Add Travis CI support","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2015-10-12T20:10:45Z","receivedAt":"2015-10-12T20:10:45Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Lars Schneider writes:\n\n> {Linux | OSX} * {gcc | clang} * {Default, NO_PTHREAD, NO_CURL, NO_OPENSSL, NO_MMAP, NO_IPV6, NO_PERL}\n\nAnother option would be to have a single \"NO_*\" build, that would\nactivate all NO_PTHREAD, NO_CURL, NO_OPENSSL, NO_MMAP, NO_IPV6, NO_PERL\nat the same time. We'd miss issues with perl but no pthread or so, but\nthis should catch most issues.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"271489","messageId":"vpqwpurx2j1.fsf@grenoble-inp.fr","threadId":"40532","inReplyTo":"1444586102-82557-2-git-send-email-larsxschneider@gmail.com","subject":"Re: [PATCH v3 1/3] Add Travis CI support","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2015-10-12T20:20:02Z","receivedAt":"2015-10-12T20:20:02Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"larsxschneider@gmail.com writes:\n\n> --- /dev/null\n> +++ b/.travis.yml\n> @@ -0,0 +1,46 @@\n> +language: c\n> +\n> +os:\n> + - linux\n> + - osx\n> +\n> +compiler:\n> + - clang\n> + - gcc\n> +\n> +before_install:\n> + - >\n> + export GIT_TEST_OPTS=\" --quiet\";\n> + case \"${TRAVIS_OS_NAME:-linux}\" in\n> + linux)\n> + wget -q https://package.perforce.com/perforce.pubkey -O - \\\n> + | sudo apt-key add -\n> + echo 'deb http://package.perforce.com/apt/ubuntu precise release' \\\n> + | sudo tee -a /etc/apt/sources.list\n> + wget -q https://packagecloud.io/gpg.key -O - | sudo apt-key add -\n> + echo 'deb https://packagecloud.io/github/git-lfs/debian/ jessie main' \\\n> + | sudo tee -a /etc/apt/sources.list\n> + sudo apt-get update -qq\n> + sudo apt-get install -y apt-transport-https\n> + sudo apt-get install perforce-server git-lfs\n\nSorry if this has been discussed already, but do you really need these\n\"sudo\" calls?\n\nThey trigger builds on the legacy Travis CI infrastructure:\n\n http://docs.travis-ci.com/user/migrating-from-legacy/?utm_source=legacy-notice&utm_medium=banner&utm_campaign=legacy-upgrade\n\nNo big deal, but getting rid of sudo would be cool, and documenting why\nit can't easily be done in commit message and/or comments would be nice\notherwise.\n\nThanks for working on that!\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"271569","messageId":"561CDDBA.609@gmail.com","threadId":"40532","inReplyTo":"1444586102-82557-2-git-send-email-larsxschneider@gmail.com","subject":"Re: [PATCH v3 1/3] Add Travis CI support","fromName":"Jean-Noël Avila","fromEmail":"avila.jn@gmail.com","sentAt":"2015-10-13T10:32:26Z","receivedAt":"2015-10-13T10:32:26Z","isPatch":true,"sender":{"key":"jn.avila@free.fr","avatar":"https://avatars.githubusercontent.com/u/156172?v=4"},"body":"Le 11/10/2015 19:55, larsxschneider@gmail.com a écrit :\n> +\n> +before_script: make\n> +\n> +script: make --quiet test\n\nTravis can be used in container mode but that would need getting rid of\n\"sudo\" command and only installing from white-listed sources\n(https://github.com/travis-ci/apt-source-whitelist/blob/master/ubuntu.json)\n\nAnyway, even within the present VM mode, 1.5 cores are available, so it\nmakes sense to add \"-j2\" to every make commands.\n\n \n"},{"id":"271706","messageId":"1B50DC8E-45CC-4D9A-80A1-6391D762A81C@gmail.com","threadId":"40532","inReplyTo":"vpqwpurx2j1.fsf@grenoble-inp.fr","subject":"Re: [PATCH v3 1/3] Add Travis CI support","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2015-10-14T22:52:20Z","receivedAt":"2015-10-14T22:52:20Z","isPatch":true,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\nOn 12 Oct 2015, at 22:20, Matthieu Moy wrote:\n\n> larsxschneider@gmail.com writes:\n> \n>> --- /dev/null\n>> +++ b/.travis.yml\n>> @@ -0,0 +1,46 @@\n>> +language: c\n>> +\n>> +os:\n>> + - linux\n>> + - osx\n>> +\n>> +compiler:\n>> + - clang\n>> + - gcc\n>> +\n>> +before_install:\n>> + - >\n>> + export GIT_TEST_OPTS=\" --quiet\";\n>> + case \"${TRAVIS_OS_NAME:-linux}\" in\n>> + linux)\n>> + wget -q https://package.perforce.com/perforce.pubkey -O - \\\n>> + | sudo apt-key add -\n>> + echo 'deb http://package.perforce.com/apt/ubuntu precise release' \\\n>> + | sudo tee -a /etc/apt/sources.list\n>> + wget -q https://packagecloud.io/gpg.key -O - | sudo apt-key add -\n>> + echo 'deb https://packagecloud.io/github/git-lfs/debian/ jessie main' \\\n>> + | sudo tee -a /etc/apt/sources.list\n>> + sudo apt-get update -qq\n>> + sudo apt-get install -y apt-transport-https\n>> + sudo apt-get install perforce-server git-lfs\n> \n> Sorry if this has been discussed already, but do you really need these\n> \"sudo\" calls?\n> \n> They trigger builds on the legacy Travis CI infrastructure:\n> \n> http://docs.travis-ci.com/user/migrating-from-legacy/?utm_source=legacy-notice&utm_medium=banner&utm_campaign=legacy-upgrade\n> \n> No big deal, but getting rid of sudo would be cool, and documenting why\n> it can't easily be done in commit message and/or comments would be nice\n> otherwise.\nI would like to get rid of the \"sudo\" calls, too. Unfortunately I wasn't able to achieve this so far because these packages are not white listed on Travis CI (see Jean-Noël answer in this thread). I tried to download and install the *.deb files manually using dpkg without luck. Any idea or hint?\nNevertheless I don't think this is a problem as Travis CI states that \"sudo isn't possible (__right now__)\" on the new infrastructure. They need to find a solutions because I believe many projects will run into this issue...\nhttp://docs.travis-ci.com/user/migrating-from-legacy/?utm_source=legacy-notice&utm_medium=banner&utm_campaign=legacy-upgrade#Using-sudo-isn%E2%80%99t-possible-(right-now)\n\n- Lars"},{"id":"271717","messageId":"14146E1E-857D-416B-9287-F20826DCB806@gmail.com","threadId":"40532","inReplyTo":"561CDDBA.609@gmail.com","subject":"Re: [PATCH v3 1/3] Add Travis CI support","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2015-10-15T07:59:32Z","receivedAt":"2015-10-15T07:59:32Z","isPatch":true,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\nOn 13 Oct 2015, at 12:32, Jean-Noël Avila wrote:\n\n> Le 11/10/2015 19:55, larsxschneider@gmail.com a écrit :\n>> +\n>> +before_script: make\n>> +\n>> +script: make --quiet test\n> \n> Travis can be used in container mode but that would need getting rid of\n> \"sudo\" command and only installing from white-listed sources\n> (https://github.com/travis-ci/apt-source-whitelist/blob/master/ubuntu.json)\n> \n> Anyway, even within the present VM mode, 1.5 cores are available, so it\n> makes sense to add \"-j2\" to every make commands.\n> \nI was reluctant to this because I feared problems. Especially while running tests in parallel. However, the result looks quite good.\n\nmake -j2 9min 11sec:\nhttps://travis-ci.org/larsxschneider/git/jobs/85478022\n\nmake 17min 20sec:\nhttps://travis-ci.org/larsxschneider/git/jobs/85432398\n\nIf there is no argument against running test in parallel then I will add it to the next roll.\n\nThanks,\nLars"},{"id":"271719","messageId":"vpq37xc4ksz.fsf@grenoble-inp.fr","threadId":"40532","inReplyTo":"1B50DC8E-45CC-4D9A-80A1-6391D762A81C@gmail.com","subject":"Re: [PATCH v3 1/3] Add Travis CI support","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2015-10-15T08:07:08Z","receivedAt":"2015-10-15T08:07:08Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Lars Schneider writes:\n\n> I would like to get rid of the \"sudo\" calls, too. Unfortunately I\n> wasn't able to achieve this so far because these packages are not\n> white listed on Travis CI (see Jean-Noël answer in this thread).\n\nI think this would deserve a mention in the commit message, but I won't\ninsist on that.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"271721","messageId":"vpqwpuo35zo.fsf@grenoble-inp.fr","threadId":"40532","inReplyTo":"14146E1E-857D-416B-9287-F20826DCB806@gmail.com","subject":"Re: [PATCH v3 1/3] Add Travis CI support","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2015-10-15T08:12:27Z","receivedAt":"2015-10-15T08:12:27Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Lars Schneider writes:\n\n> I was reluctant to this because I feared problems. Especially while\n> running tests in parallel.\n\nIsn't the point of using a CI tool to notice problems? ;-)\n\nMore seriously, running tests in parallel shouldn't be a problem since\neach test runs in its own directory with HOME set to this private\ndirectory, so two diffent tests should not interfer. If there's an issue\nwith parallel tests, we probably prefer discovering them than avoiding\nthem.\n\n> make -j2 9min 11sec:\n> https://travis-ci.org/larsxschneider/git/jobs/85478022\n>\n> make 17min 20sec:\n> https://travis-ci.org/larsxschneider/git/jobs/85432398\n\nSince the tests are essentially IO-bound and not CPU-bound, it may even\nmake sense to use -j3 here.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"271722","messageId":"561F6BB4.8080202@gmail.com","threadId":"40532","inReplyTo":"1B50DC8E-45CC-4D9A-80A1-6391D762A81C@gmail.com","subject":"Re: [PATCH v3 1/3] Add Travis CI support","fromName":"Jean-Noël Avila","fromEmail":"avila.jn@gmail.com","sentAt":"2015-10-15T09:02:44Z","receivedAt":"2015-10-15T09:02:44Z","isPatch":true,"sender":{"key":"jn.avila@free.fr","avatar":"https://avatars.githubusercontent.com/u/156172?v=4"},"body":"Le 15/10/2015 00:52, Lars Schneider a écrit :\n> On 12 Oct 2015, at 22:20, Matthieu Moy wrote:\n>\n>> larsxschneider@gmail.com writes:\n>>\n>>> --- /dev/null\n>>> +++ b/.travis.yml\n>>> @@ -0,0 +1,46 @@\n>>> +language: c\n>>> +\n>>> +os:\n>>> + - linux\n>>> + - osx\n>>> +\n>>> +compiler:\n>>> + - clang\n>>> + - gcc\n>>> +\n>>> +before_install:\n>>> + - >\n>>> + export GIT_TEST_OPTS=\" --quiet\";\n>>> + case \"${TRAVIS_OS_NAME:-linux}\" in\n>>> + linux)\n>>> + wget -q https://package.perforce.com/perforce.pubkey -O - \\\n>>> + | sudo apt-key add -\n>>> + echo 'deb http://package.perforce.com/apt/ubuntu precise release' \\\n>>> + | sudo tee -a /etc/apt/sources.list\n>>> + wget -q https://packagecloud.io/gpg.key -O - | sudo apt-key add -\n>>> + echo 'deb https://packagecloud.io/github/git-lfs/debian/ jessie main' \\\n>>> + | sudo tee -a /etc/apt/sources.list\n>>> + sudo apt-get update -qq\n>>> + sudo apt-get install -y apt-transport-https\n>>> + sudo apt-get install perforce-server git-lfs\n>> Sorry if this has been discussed already, but do you really need these\n>> \"sudo\" calls?\n>>\n>> They trigger builds on the legacy Travis CI infrastructure:\n>>\n>> http://docs.travis-ci.com/user/migrating-from-legacy/?utm_source=legacy-notice&utm_medium=banner&utm_campaign=legacy-upgrade\n>>\n>> No big deal, but getting rid of sudo would be cool, and documenting why\n>> it can't easily be done in commit message and/or comments would be nice\n>> otherwise.\n> I would like to get rid of the \"sudo\" calls, too. Unfortunately I wasn't able to achieve this so far because these packages are not white listed on Travis CI (see Jean-Noël answer in this thread). I tried to download and install the *.deb files manually using dpkg without luck. Any idea or hint?\n> Nevertheless I don't think this is a problem as Travis CI states that \"sudo isn't possible (__right now__)\" on the new infrastructure. They need to find a solutions because I believe many projects will run into this issue...\n> http://docs.travis-ci.com/user/migrating-from-legacy/?utm_source=legacy-notice&utm_medium=banner&utm_campaign=legacy-upgrade#Using-sudo-isn%E2%80%99t-possible-(right-now)\n>\n> - Lars\n\n\nThere's another hope. The requirements can be installed in the user's\nHOME and cached between builds. In this case, no need for sudo.\nObviously, that rules out using apt and dpkg.\n\nJean-Noël\n"},{"id":"271726","messageId":"F501FD44-F14B-4902-9E24-149451804C1C@gmail.com","threadId":"40532","inReplyTo":"vpqwpuo35zo.fsf@grenoble-inp.fr","subject":"Re: [PATCH v3 1/3] Add Travis CI support","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2015-10-15T10:35:46Z","receivedAt":"2015-10-15T10:35:46Z","isPatch":true,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\nOn 15 Oct 2015, at 10:12, Matthieu Moy wrote:\n\n> Lars Schneider writes:\n> \n>> I was reluctant to this because I feared problems. Especially while\n>> running tests in parallel.\n> \n> Isn't the point of using a CI tool to notice problems? ;-)\n> \n> More seriously, running tests in parallel shouldn't be a problem since\n> each test runs in its own directory with HOME set to this private\n> directory, so two diffent tests should not interfer. If there's an issue\n> with parallel tests, we probably prefer discovering them than avoiding\n> them.\nOK. Great!\n\n\n>> make -j2 9min 11sec:\n>> https://travis-ci.org/larsxschneider/git/jobs/85478022\n>> \n>> make 17min 20sec:\n>> https://travis-ci.org/larsxschneider/git/jobs/85432398\n> \n> Since the tests are essentially IO-bound and not CPU-bound, it may even\n> make sense to use -j3 here.\nHehe you're right.\n\nmake -j3 6min 2sec\nhttps://travis-ci.org/larsxschneider/git/jobs/85497307\n\njust for fun I tried a few more values and -j5 seems to be the best with 4min 27sec\nhttps://travis-ci.org/larsxschneider/git/jobs/85501015\n\n-j6 is slower again. Do you see a reason not to use \"-j5\"?\n\nThanks,\nLars\n"},{"id":"271727","messageId":"alpine.DEB.1.00.1510151247550.31610@s15462909.onlinehome-server.info","threadId":"40532","inReplyTo":"vpqwpuo35zo.fsf@grenoble-inp.fr","subject":"Re: [PATCH v3 1/3] Add Travis CI support","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2015-10-15T10:50:35Z","receivedAt":"2015-10-15T10:50:35Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 15 Oct 2015, Matthieu Moy wrote:\n\n> Lars Schneider writes:\n> \n> > I was reluctant to this because I feared problems. Especially while\n> > running tests in parallel.\n> \n> Isn't the point of using a CI tool to notice problems? ;-)\n> \n> More seriously, running tests in parallel shouldn't be a problem since\n> each test runs in its own directory with HOME set to this private\n> directory, so two diffent tests should not interfer. If there's an issue\n> with parallel tests, we probably prefer discovering them than avoiding\n> them.\n\nI vividly remember pulling my hair out over BuildHive (i.e. the Java-based\nJenkins alternative to Travis) failures that turned out to be\nresource-related: I simply overloaded the BuildHive node.\n\nSo I assumed that the problems Lars referred to would not be problems of\nGit, or the test suite, but of overwhelming a free service with an\nunreasonable load.\n\n> > make -j2 9min 11sec:\n> > https://travis-ci.org/larsxschneider/git/jobs/85478022\n> >\n> > make 17min 20sec:\n> > https://travis-ci.org/larsxschneider/git/jobs/85432398\n> \n> Since the tests are essentially IO-bound and not CPU-bound, it may even\n> make sense to use -j3 here.\n\nI would like to caution against overloading Travis. They are really nice\nto us, we should try to be nice to them, too.\n\nCiao,\nDscho\n"},{"id":"271741","messageId":"vpq7fmoyryw.fsf@grenoble-inp.fr","threadId":"40532","inReplyTo":"alpine.DEB.1.00.1510151247550.31610@s15462909.onlinehome-server.info","subject":"Re: [PATCH v3 1/3] Add Travis CI support","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2015-10-15T17:14:15Z","receivedAt":"2015-10-15T17:14:15Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Johannes Schindelin writes:\n\n> On Thu, 15 Oct 2015, Matthieu Moy wrote:\n>\n>> Since the tests are essentially IO-bound and not CPU-bound, it may even\n>> make sense to use -j3 here.\n>\n> I would like to caution against overloading Travis. They are really nice\n> to us, we should try to be nice to them, too.\n\nRight.\n\nUsing a bit of parallelism shouldn't harm (we put a heavier load on\nthem, but for a shorter time), so using -j2 or -j3 seems OK to me, but I\nwouldn't go higher to remain gentle with Travis CI.\n\nNote: I'm writting this without having a real idea of what consequence\nof -jN have on their infrastructure, take my writing as wild guess, not\nas real arguments.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"}]}