{"thread":{"id":"40426","subject":"[RFC/PATCH v1] Add Travis CI support","startedAt":"2015-09-24T21:43:23Z","lastAt":"2015-10-12T08:03:37Z","messageCount":31,"participants":["larsxschneider@gmail.com","Junio C Hamano","Dennis Kaarsemaker","Johannes Schindelin","Luke Diamand","Jeff King","Lars Schneider","Shawn Pearce","Matthieu Moy","Stefan Beller","Sebastian Schuberth","Roberto Tyley"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"270723","messageId":"1443131004-39284-1-git-send-email-larsxschneider@gmail.com","threadId":"40426","inReplyTo":null,"subject":"[RFC/PATCH v1] Add Travis CI support","fromName":"","fromEmail":"larsxschneider@gmail.com","sentAt":"2015-09-24T21:43:23Z","receivedAt":"2015-09-24T21:43:23Z","isPatch":true,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"From: Lars Schneider \n\nHi,\n\nI recently broke a few tests...\n\nIn order to avoid that in the future I configured Travis CI for Git. With this\npatch Travis can run all Git tests including the \"git-p4\" and \"Git-LFS\" tests.\n\nThe tests are executed on \"Ubuntu 12.04 LTS Server Edition 64 bit\" and on\n\"OS X Mavericks\" using gcc and clang.\n\nMy idea is that the owner of \"https://github.com/git/git\" enables this account\nfor Travis (it's free!). Then we would automatically get the test state for all\nofficial branches.\n\nEvery contributor can enable Travis for their respective GitHub accounts. Then\nthey would know if their patches pass all tests in advance, too.\n\nYou can see the state of my branches here:\nhttps://travis-ci.org/larsxschneider/git/branches\n\nIt's pretty red. The reason is that maint, master, and next have a failure on\nOS X (test \"t9815-git-p4-submit-fail.sh\" does not pass). Furthmore pu does not\npass on either Linux or OS X (which is propably OK since it is pu).\n\nYou can also inspect the build/test logs. Here for instance the log for the\nnext branch compiled on Linux with gcc:\nhttps://travis-ci.org/larsxschneider/git/jobs/82032861\n\nCheers,\nLars\n\nLars Schneider (1):\n Add Travis CI support\n\n .travis.yml | 28 ++++++++++++++++++++++++++++\n 1 file changed, 28 insertions(+)\n create mode 100644 .travis.yml\n\n--\n2.5.1\n"},{"id":"270724","messageId":"1443131004-39284-2-git-send-email-larsxschneider@gmail.com","threadId":"40426","inReplyTo":"1443131004-39284-1-git-send-email-larsxschneider@gmail.com","subject":"[RFC/PATCH v1] Add Travis CI support","fromName":"","fromEmail":"larsxschneider@gmail.com","sentAt":"2015-09-24T21:43:24Z","receivedAt":"2015-09-24T21:43:24Z","isPatch":true,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"From: Lars Schneider \n\nThe tests are executed on \"Ubuntu 12.04 LTS Server Edition 64 bit\" and\non \"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 | 28 ++++++++++++++++++++++++++++\n 1 file changed, 28 insertions(+)\n create mode 100644 .travis.yml\n\ndiff --git a/.travis.yml b/.travis.yml\nnew file mode 100644\nindex 0000000..056cc99\n--- /dev/null\n+++ b/.travis.yml\n@@ -0,0 +1,28 @@\n+language: c\n+\n+os:\n+ - linux\n+ - osx\n+\n+compiler:\n+ - clang\n+ - gcc\n+\n+before_script:\n+ - \"if [ ${TRAVIS_OS_NAME:-'linux'} = 'linux' ]; then wget -q https://package.perforce.com/perforce.pubkey -O - | sudo apt-key add -; fi\"\n+ - \"if [ ${TRAVIS_OS_NAME:-'linux'} = 'linux' ]; then echo 'deb http://package.perforce.com/apt/ubuntu precise release' | sudo tee -a /etc/apt/sources.list; fi\"\n+ - \"if [ ${TRAVIS_OS_NAME:-'linux'} = 'linux' ]; then sudo apt-get update -qq; fi\"\n+ - \"if [ ${TRAVIS_OS_NAME:-'linux'} = 'linux' ]; then sudo apt-get install perforce-server; fi\"\n+ - \"if [ ${TRAVIS_OS_NAME:-'linux'} = 'linux' ]; then wget -q https://packagecloud.io/gpg.key -O - | sudo apt-key add -; fi\"\n+ - \"if [ ${TRAVIS_OS_NAME:-'linux'} = 'linux' ]; then sudo apt-get install -y apt-transport-https; fi\"\n+ - \"if [ ${TRAVIS_OS_NAME:-'linux'} = 'linux' ]; then echo 'deb https://packagecloud.io/github/git-lfs/debian/ wheezy main' | sudo tee -a /etc/apt/sources.list; fi\"\n+ - \"if [ ${TRAVIS_OS_NAME:-'linux'} = 'linux' ]; then sudo apt-get update -qq; fi\"\n+ - \"if [ ${TRAVIS_OS_NAME:-'linux'} = 'linux' ]; then sudo apt-get install git-lfs; fi\"\n+ - \"if [ ${TRAVIS_OS_NAME:-'linux'} = 'osx' ]; then brew update; fi\"\n+ - \"if [ ${TRAVIS_OS_NAME:-'linux'} = 'osx' ]; then brew install git-lfs; fi\"\n+ - \"if [ ${TRAVIS_OS_NAME:-'linux'} = 'osx' ]; then brew tap homebrew/binary; fi\"\n+ - \"if [ ${TRAVIS_OS_NAME:-'linux'} = 'osx' ]; then sed -i.bak 's/b42758ebe7b54e672b513c34c88f399d0da7b4de1fd23b9f56d222a4f1f3bae5/e987475bfc54129d8d54a0d54363db3ecf6e6852a00daa0c6ffc20b8df1e0e63/' /usr/local/Library/Taps/homebrew/homebrew-binary/perforce-server.rb; fi\"\n+ - \"if [ ${TRAVIS_OS_NAME:-'linux'} = 'osx' ]; then brew install perforce; fi\"\n+ - \"if [ ${TRAVIS_OS_NAME:-'linux'} = 'osx' ]; then brew install perforce-server; fi\"\n+\n+install: make configure\n--\n2.5.1\n"},{"id":"270731","messageId":"xmqqeghnuy8t.fsf@gitster.mtv.corp.google.com","threadId":"40426","inReplyTo":"1443131004-39284-1-git-send-email-larsxschneider@gmail.com","subject":"Re: [RFC/PATCH v1] Add Travis CI support","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-09-25T00:41:06Z","receivedAt":"2015-09-25T00:41:06Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"larsxschneider@gmail.com writes:\n\n> In order to avoid that in the future I configured Travis CI for Git. With this\n> patch Travis can run all Git tests including the \"git-p4\" and \"Git-LFS\" tests.\n\nInteresting. I was wondering about the \"p4\" part myself.\n\n> My idea is that the owner of \"https://github.com/git/git\" enables this account\n> for Travis (it's free!). Then we would automatically get the test state for all\n> official branches.\n\nThe last time I heard about this \"it's free\" thing, I thought I\nheard that it wants write access to the repository. If that is\nstill the case, the history stored in the GitHub repository the\n\"it's free\" thing has access to can become even less trustworthy\nthan it currently is. Those who clone/fetch from it cannot be sure\nif the tips of branches are what I pushed there, or they were\nchanged to a malicious replacement from sideways by the \"it's free\"\nthing, taking advantage of that write access.\n\nGranted, those who clone/fetch cannot be sure unless they trust\nGitHub. The only assurance they have is GitHub's word: \"gitster has\naccount with us, gitster pushes into this repository, and we have\nACL to ensure that gitster is the only person that can update this\nrepository\". Allowing write-access to a third-party will break that\nassurance, even if you trust GitHub.\n\nOf course, this can be improved if we start using signed push into\nGitHub. It is a separate issue in the sense that it would help\nGitHub to make that assurance stronger---those who fetch/clone can\nbe assured that the tips of branches are what I pushed, without even\ntrusting GitHub.\n"},{"id":"270738","messageId":"1443150875.3042.3.camel@kaarsemaker.net","threadId":"40426","inReplyTo":"xmqqeghnuy8t.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC/PATCH v1] Add Travis CI support","fromName":"Dennis Kaarsemaker","fromEmail":"dennis@kaarsemaker.net","sentAt":"2015-09-25T03:14:35Z","receivedAt":"2015-09-25T03:14:35Z","isPatch":true,"sender":{"key":"dennis@kaarsemaker.net","avatar":"https://avatars.githubusercontent.com/u/200649?v=4"},"body":"On do, 2015-09-24 at 17:41 -0700, Junio C Hamano wrote:\n> larsxschneider@gmail.com writes:\n> \n> > My idea is that the owner of \"https://github.com/git/git\" enables this account\n> > for Travis (it's free!). Then we would automatically get the test state for all\n> > official branches.\n> \n> The last time I heard about this \"it's free\" thing, I thought I\n> heard that it wants write access to the repository.\n\nIt does not need write access to the git data, only to auxiliary GitHub\ndata: commit status and deployment status (where it can put \"this\ncommit failed tests\"), repository hooks (to set up build triggers),\nteam membership (ro) and email addresses (ro).\n-- \nDennis Kaarsemaker\nwww.kaarsemaker.net\n"},{"id":"270740","messageId":"699c08632232180166145f70c7f16645@dscho.org","threadId":"40426","inReplyTo":"1443150875.3042.3.camel@kaarsemaker.net","subject":"Re: [RFC/PATCH v1] Add Travis CI support","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2015-09-25T07:27:19Z","receivedAt":"2015-09-25T07:27:19Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn 2015-09-25 05:14, Dennis Kaarsemaker wrote:\n> On do, 2015-09-24 at 17:41 -0700, Junio C Hamano wrote:\n>> larsxschneider@gmail.com writes:\n>>\n>> > My idea is that the owner of \"https://github.com/git/git\" enables this account\n>> > for Travis (it's free!). Then we would automatically get the test state for all\n>> > official branches.\n>>\n>> The last time I heard about this \"it's free\" thing, I thought I\n>> heard that it wants write access to the repository.\n> \n> It does not need write access to the git data, only to auxiliary GitHub\n> data: commit status and deployment status (where it can put \"this\n> commit failed tests\"), repository hooks (to set up build triggers),\n> team membership (ro) and email addresses (ro).\n\nIf that still elicits concerns, a fork could be set up that is automatically kept up-to-date via a web hook, and enable Travis CI there.\n\nJunio, if that is something with which you feel more comfortable, I would be willing to set it up. Even if the visibility (read: impact) would be higher if the badges were attached to https://github.com/git/git proper...\n\nCiao,\nDscho\n"},{"id":"270741","messageId":"CAE5ih7_f8qy9WvmgRUR6-qFwB4WFhZ6Qr5iOpE0YxqJH8AsZyw@mail.gmail.com","threadId":"40426","inReplyTo":"699c08632232180166145f70c7f16645@dscho.org","subject":"Re: [RFC/PATCH v1] Add Travis CI support","fromName":"Luke Diamand","fromEmail":"luke@diamand.org","sentAt":"2015-09-25T08:05:37Z","receivedAt":"2015-09-25T08:05:37Z","isPatch":true,"sender":{"key":"luke@diamand.org","avatar":"https://avatars.githubusercontent.com/u/5330967?v=4"},"body":"On 25 September 2015 at 08:27, Johannes Schindelin\n wrote:\n> Hi,\n>\n> On 2015-09-25 05:14, Dennis Kaarsemaker wrote:\n>> On do, 2015-09-24 at 17:41 -0700, Junio C Hamano wrote:\n>>> larsxschneider@gmail.com writes:\n>>>\n>>> > My idea is that the owner of \"https://github.com/git/git\" enables this account\n>>> > for Travis (it's free!). Then we would automatically get the test state for all\n>>> > official branches.\n>>>\n>>> The last time I heard about this \"it's free\" thing, I thought I\n>>> heard that it wants write access to the repository.\n>>\n>> It does not need write access to the git data, only to auxiliary GitHub\n>> data: commit status and deployment status (where it can put \"this\n>> commit failed tests\"), repository hooks (to set up build triggers),\n>> team membership (ro) and email addresses (ro).\n>\n> If that still elicits concerns, a fork could be set up that is automatically kept up-to-date via a web hook, and enable Travis CI there.\n>\n> Junio, if that is something with which you feel more comfortable, I would be willing to set it up. Even if the visibility (read: impact) would be higher if the badges were attached to https://github.com/git/git proper...\n>\n\nIt would be less intrusive for the CI system to have a fork. Otherwise\nother people using git with the same CI system will get annoying merge\nconflicts, and we'll also end up with a repo littered with the control\nfiles from past CI systems if the CI system is ever changed.\n\n>From past experience, if it's configured to email people when things\nbreak, sooner or later it will email the wrong people, probably once\nevery few seconds over a weekend.\n\nAutomated testing is a Good Thing, but it's still software, so needs\nmaintenance or it will break.\n\n\nLuke\n"},{"id":"270755","messageId":"20150925162615.GF8417@sigill.intra.peff.net","threadId":"40426","inReplyTo":"xmqqeghnuy8t.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC/PATCH v1] Add Travis CI support","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-09-25T16:26:16Z","receivedAt":"2015-09-25T16:26:16Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Sep 24, 2015 at 05:41:06PM -0700, Junio C Hamano wrote:\n\n> Of course, this can be improved if we start using signed push into\n> GitHub. It is a separate issue in the sense that it would help\n> GitHub to make that assurance stronger---those who fetch/clone can\n> be assured that the tips of branches are what I pushed, without even\n> trusting GitHub.\n\nIt's been on my todo list to investigate this further, but I just\nhaven't gotten around to it. My understanding is that GitHub would need\nto store your signed-push certificate somewhere (e.g., in a git tree\nthat records all of the push certs).\n\nIf the point is for clients not to trust GitHub, though, it doesn't\nreally matter what GitHub does with the cert, as long as it is put\nsomewhere that clients know to get it. So I wonder if it would be\nhelpful to have a microformat that the client would use to look at this.\nE.g., it would fetch the cert tree, then confirm that the current ref\nvalues match the latest cert.\n\n-Peff\n"},{"id":"270758","messageId":"xmqqsi624cs0.fsf@gitster.mtv.corp.google.com","threadId":"40426","inReplyTo":"CAE5ih7_f8qy9WvmgRUR6-qFwB4WFhZ6Qr5iOpE0YxqJH8AsZyw@mail.gmail.com","subject":"Re: [RFC/PATCH v1] Add Travis CI support","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-09-25T17:41:35Z","receivedAt":"2015-09-25T17:41:35Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Luke Diamand writes:\n\n> From past experience, if it's configured to email people when things\n> break, sooner or later it will email the wrong people, probably once\n> every few seconds over a weekend.\n>\n> Automated testing is a Good Thing, but it's still software, so needs\n> maintenance or it will break.\n\nThat does sound like a valid concern (thanks for education---we\nshould all learn from others' past experience). Unless it is just a\n\"set up and forget\" thing, I do not think I'd want to be in charge\nof it.\n\nThanks.\n"},{"id":"270762","messageId":"xmqqa8sa4ak4.fsf@gitster.mtv.corp.google.com","threadId":"40426","inReplyTo":"20150925162615.GF8417@sigill.intra.peff.net","subject":"Re: [RFC/PATCH v1] Add Travis CI support","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-09-25T18:29:31Z","receivedAt":"2015-09-25T18:29:31Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> If the point is for clients not to trust GitHub, though, it doesn't\n> really matter what GitHub does with the cert, as long as it is put\n> somewhere that clients know to get it.\n\nCorrect. A spiffy Web interface that says \"Click this button and we\nshow you the output of GPG signature verification\" would not help.\nThe push certificate is all about allowing third-parties to conduct\nan independent audit, so anything the hosting site computes using\nthe certificates does not add value, unless the certificates\nthemselves are exported for such an independent audit.\n\nIf somebody found a change to \"git push\" that makes it pick the\nuser's wallet and sends a few coins every time it talks to the\nhosting site, the hosting site can say it is not their doing by\nshowing that the tip of the commit that contains such a change came\nfrom me, and it is not their evil doing. Push certificates help the\nhosting site prove their innocence, and those who do not trust the\nsite can still be convinced by the claim.\n\nThere is one scenario that signed push would not help very much,\nthough. The hosting site cannot deny that it did not receive a\npush.\n\nFollowing such an incident (perhaps the evil change came as a side\neffect of a innocuous looking patch), I would push a commit that\nfixes such an issue out to the hosting site (with signed commit).\nBut if the hosting site deliberately keeps the tip of the branch\nunmodified (e.g. you can appear to accept the push to the pusher,\nwithout updating what is served to the general public), there will\nbe more people who will fetch from the hosting site to contaminate\ntheir copy of git and the damage will spread in the meantime.\n\nWhen I finally complain to the hosting site that it is deliberately\nrejecting the fix that would rob them the illicit revenue source, it\ndoes not help the hosting site to keep copies of push certificates\nwhen it wants to refute such a complaint. \"We publish all push\ncertificates and there is no record that gitster already tried to\nfix the issue\" has to be taken with faith in that scenario.\n\nSo push certificate is not perfect. But it does protect hosting\nsites and projects hosted on them.\n\n> So I wonder if it would be\n> helpful to have a microformat that the client would use to look at this.\n> E.g., it would fetch the cert tree, then confirm that the current ref\n> values match the latest cert.\n\nYeah, that is one possibility. Just a single flat file that\nconcatenates all the push cert in the received order would do as an\nexport format, too ;-)\n"},{"id":"270764","messageId":"20150925185227.GA15190@sigill.intra.peff.net","threadId":"40426","inReplyTo":"xmqqa8sa4ak4.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC/PATCH v1] Add Travis CI support","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-09-25T18:52:27Z","receivedAt":"2015-09-25T18:52:27Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Sep 25, 2015 at 11:29:31AM -0700, Junio C Hamano wrote:\n\n> When I finally complain to the hosting site that it is deliberately\n> rejecting the fix that would rob them the illicit revenue source, it\n> does not help the hosting site to keep copies of push certificates\n> when it wants to refute such a complaint. \"We publish all push\n> certificates and there is no record that gitster already tried to\n> fix the issue\" has to be taken with faith in that scenario.\n\nRight. Your earlier examples showed non-repudiation by the original\nsigner (the hosting site says \"you definite pushed this to us, and here\nis the signature to prove it, so you cannot deny it\"). But in this\nexample, it is going the other way: the pusher wants the hosting site to\nadmit to an action.\n\nTo do that, the hosting site would have to re-sign the push cert to say\n\"we got this, it is published\", and return the receipt to the original\npusher, who can then use it as proof of the event. Or alternatively, it\ncould be signed by a third-party notary.\n\nI don't think it is all that interesting an avenue to pursue, though. If\nyou say \"I have this update and the hosting site is not providing it to\npeople\", people are not that interested in whether the hosting site is\nbeing laggy, malicious, or whatever. They are interested in getting your\nupdate. :)\n\nSo the more general problem is \"I want to make sure I have Junio's\nlatest push, and I do not want to trust anything else\". For that, you\ncould publish expiring certs (so you can fool me for up to, say, a week,\nbut after that I consider the old certs to be garbage either way). Or\nyou could do something clever with a quorum (e.g., N of K hosting sites\nsay there is no update, so there probably isn't one).\n\nBut I think all of that is outside of git's scope. Git provides the\nsigned ref-state in the form of a push cert. Since it's a small-ish blob\nof data, you can use any external mechanism you want to decide on the\ncorrect value of it.\n\n> > So I wonder if it would be\n> > helpful to have a microformat that the client would use to look at this.\n> > E.g., it would fetch the cert tree, then confirm that the current ref\n> > values match the latest cert.\n> \n> Yeah, that is one possibility. Just a single flat file that\n> concatenates all the push cert in the received order would do as an\n> export format, too ;-)\n\nI agree that's a more logical format, in a sense; it really is a linear\nlog. It's just that the receive-pack code already creates a blob for us,\nso it's cheap to reference that in tree (and then fetching it is cheap,\ntoo). IOW, git is much better at adding files to trees than it is at\nappending to files. :)\n\n-Peff\n"},{"id":"270783","messageId":"D5E16E1E-A2A7-4C05-B590-CF62ED3BA08D@gmail.com","threadId":"40426","inReplyTo":"CAE5ih7_f8qy9WvmgRUR6-qFwB4WFhZ6Qr5iOpE0YxqJH8AsZyw@mail.gmail.com","subject":"Re: [RFC/PATCH v1] Add Travis CI support","fromName":"Lars Schneider","fromEmail":"larsxschneider@gmail.com","sentAt":"2015-09-26T16:40:41Z","receivedAt":"2015-09-26T16:40:41Z","isPatch":true,"sender":{"key":"larsxschneider@gmail.com","avatar":"https://avatars.githubusercontent.com/u/477434?v=4"},"body":"\nOn 25 Sep 2015, at 10:05, Luke Diamand wrote:\n\n> On 25 September 2015 at 08:27, Johannes Schindelin\n> wrote:\n>> Hi,\n>> \n>> On 2015-09-25 05:14, Dennis Kaarsemaker wrote:\n>>> On do, 2015-09-24 at 17:41 -0700, Junio C Hamano wrote:\n>>>> larsxschneider@gmail.com writes:\n>>>> \n>>>>> My idea is that the owner of \"https://github.com/git/git\" enables this account\n>>>>> for Travis (it's free!). Then we would automatically get the test state for all\n>>>>> official branches.\n>>>> \n>>>> The last time I heard about this \"it's free\" thing, I thought I\n>>>> heard that it wants write access to the repository.\n>>> \n>>> It does not need write access to the git data, only to auxiliary GitHub\n>>> data: commit status and deployment status (where it can put \"this\n>>> commit failed tests\"), repository hooks (to set up build triggers),\n>>> team membership (ro) and email addresses (ro).\n>> \n>> If that still elicits concerns, a fork could be set up that is automatically kept up-to-date via a web hook, and enable Travis CI there.\n>> \n>> Junio, if that is something with which you feel more comfortable, I would be willing to set it up. Even if the visibility (read: impact) would be higher if the badges were attached to https://github.com/git/git proper...\n>> \n> \n> It would be less intrusive for the CI system to have a fork. Otherwise\n> other people using git with the same CI system will get annoying merge\n> conflicts, and we'll also end up with a repo littered with the control\n> files from past CI systems if the CI system is ever changed.\n> \n> From past experience, if it's configured to email people when things\n> break, sooner or later it will email the wrong people, probably once\n> every few seconds over a weekend.\n> \n> Automated testing is a Good Thing, but it's still software, so needs\n> maintenance or it will break.\n\nI completely agree with your argument about emails and that software needs maintenance. We could setup this CI to not send any emails. We still could inspect the build/test state of each branch on the Travis CI website. I believe this is valuable because not everyone has e.g. a Mac system at hand to run all tests. This is no theoretical example because t9819 is broken on maint using a Mac.\n\nLars"},{"id":"270786","messageId":"CAJo=hJuj04nZS3qPe+QcvihoMVJ1JUL7eG5gdVU-V_FPdLn1tQ@mail.gmail.com","threadId":"40426","inReplyTo":"20150925185227.GA15190@sigill.intra.peff.net","subject":"Re: [RFC/PATCH v1] Add Travis CI support","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2015-09-26T21:54:55Z","receivedAt":"2015-09-26T21:54:55Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"On Fri, Sep 25, 2015 at 11:52 AM, Jeff King wrote:\n> On Fri, Sep 25, 2015 at 11:29:31AM -0700, Junio C Hamano wrote:\n>\n>> > So I wonder if it would be\n>> > helpful to have a microformat that the client would use to look at this.\n>> > E.g., it would fetch the cert tree, then confirm that the current ref\n>> > values match the latest cert.\n>>\n>> Yeah, that is one possibility. Just a single flat file that\n>> concatenates all the push cert in the received order would do as an\n>> export format, too ;-)\n>\n> I agree that's a more logical format, in a sense; it really is a linear\n> log. It's just that the receive-pack code already creates a blob for us,\n> so it's cheap to reference that in tree (and then fetching it is cheap,\n> too). IOW, git is much better at adding files to trees than it is at\n> appending to files. :)\n\nFWIW JGit has a micro-format[1] we are starting to use. Its a tree of\nthe push cert blobs anchored under refs/meta/push-certs.\n\nInspired by a proposal from gitolite[2], where we store a file in\na tree for each ref name, and the contents of the file is the latest\npush cert to affect that ref.\n\nThe main modification from that proposal (other than lacking the\nout-of-git batching) is to append \"@{cert}\" to filenames, which allows\nstoring certificates for both refs/foo and refs/foo/bar. Those\nrefnames cannot coexist at the same time in a repository, but we do\nnot want to discard the push certificate responsible for deleting the\nref, which we would have to do if refs/foo in the push cert tree\nchanged from a tree to a blob.\n\n[1] https://eclipse.googlesource.com/jgit/jgit/+/d5a71e9ca3d95330acdd858306c4f75ae0b01e58\n[2] https://github.com/sitaramc/gitolite/blob/cf062b8bb6b21a52f7c5002d33fbc950762c1aa7/contrib/hooks/repo-specific/save-push-signatures\n"},{"id":"270790","messageId":"vpq7fnc83ki.fsf@grenoble-inp.fr","threadId":"40426","inReplyTo":"CAE5ih7_f8qy9WvmgRUR6-qFwB4WFhZ6Qr5iOpE0YxqJH8AsZyw@mail.gmail.com","subject":"Re: [RFC/PATCH v1] Add Travis CI support","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2015-09-27T12:11:25Z","receivedAt":"2015-09-27T12:11:25Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Luke Diamand writes:\n\n> It would be less intrusive for the CI system to have a fork. Otherwise\n> other people using git with the same CI system will get annoying merge\n> conflicts,\n\nWhat conflicts are you talking about? The ones in .travis.yml? The point\nis to share this file so that people using the same system do not have\nto change anything.\n\nAnd, we're talking about a straightforward 28-lines long file, set up\nessentially once and for all. Even if people ever modify it, I don't\nforsee conflict resolution in such a simple file as a real problem.\n\n> and we'll also end up with a repo littered with the control files from\n> past CI systems if the CI system is ever changed.\n\nAgain, we're talking about a short and simple configuration file.\n\nSure, when we change something, we either get old files lying around or\nhave to remove the old files. But would we say \"Git shouldn't have a\nMakefile, because having a Makefile would mean we'd end up with a repo\nlittered with Makefiles the day we migrate to another build system\"?\n\n> From past experience, if it's configured to email people when things\n> break, sooner or later it will email the wrong people, probably once\n> every few seconds over a weekend.\n\nAre you talking about your experience with Travis-CI in particular, or\nwith CI systems in general? Is the scenario where Travis-CI sends email\nbased on actual facts, or only speculation?\n\nMy experience with Travis-CI is that it just works (my experience is\nlimited, but I'm using it for git-multimail, and it's a really\nconvenient tool). It does send emails by default, but with a very\nreasonable policy:\n\n http://docs.travis-ci.com/user/notifications/\n\n \"By default, email notifications are sent to the committer and the\n commit author, if they are members of the repository (that is, they\n have push or admin permissions for public repositories, or if they\n have pull, push or admin permissions for private repositories).\"\n\nIn short:\n\n* If the tests always pass, nobody ever get any email from Travis-CI.\n\n* When someone sends a pull-request that fails tests, that someone gets\n an automatic email about the failure. This saves one email round-trip\n \"X sends a patch series, Junio notices the failure, Junio sends an\n email about the failure\", and shortcuts this as \"X sends a PR, and\n gets an email, possibly even before Junio notices\".\n\n> Automated testing is a Good Thing, but it's still software, so needs\n> maintenance or it will break.\n\nThe point of using Travis-CI is precisely to use an externally\nmaintained system. It's not just software, it's a service (based on\nsoftware, obviously).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"270819","messageId":"CAGZ79karJa0KfMcqwXopZ5Uuh1ocDizH=fFqFDS+Jw-kTc-wng@mail.gmail.com","threadId":"40426","inReplyTo":"vpq7fnc83ki.fsf@grenoble-inp.fr","subject":"Re: [RFC/PATCH v1] Add Travis CI support","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2015-09-28T17:21:51Z","receivedAt":"2015-09-28T17:21:51Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Sun, Sep 27, 2015 at 5:11 AM, Matthieu Moy\n wrote:\n>\n> My experience with Travis-CI is that it just works\n\nI can second that.\nWhen I was contributing to other projects[1][2], Travis helped a lot.\n\nCurrently I have a cronjob to get https://scan.coverity.com/\nrunning on Git a few times a week on the pu branch\n(plus $gmane/271826). Additionally to that I could setup\na travis test to that, which would run daily on stefanbeller/pu\n(which would be a copy of junios pu branch).\n\nI just logged in to travis and it seems as if they don't require\nwrite access to the repository (any more? They used to require\nit, but now they ask for updated permissions which drops\nwrite access to a repository, but then asks for more meta\ndata permissions, such as web hooks, my email address,\nmy organizations).\n\nHaving observed that there is no reason to not turn it on on\nthe main repository (set it and forget it).\n\n[1] https://github.com/bjorn/tiled\n[2] https://github.com/clintbellanger/flare-engine\n\n\n\n>\n> http://docs.travis-ci.com/user/notifications/\n>\n> \"By default, email notifications are sent to the committer and the\n> commit author, if they are members of the repository (that is, they\n> have push or admin permissions for public repositories, or if they\n> have pull, push or admin permissions for private repositories).\"\n>\n> In short:\n>\n> * If the tests always pass, nobody ever get any email from Travis-CI.\n>\n> * When someone sends a pull-request that fails tests, that someone gets\n> an automatic email about the failure. This saves one email round-trip\n> \"X sends a patch series, Junio notices the failure, Junio sends an\n> email about the failure\", and shortcuts this as \"X sends a PR, and\n> gets an email, possibly even before Junio notices\".\n>\n>> Automated testing is a Good Thing, but it's still software, so needs\n>> maintenance or it will break.\n>\n> The point of using Travis-CI is precisely to use an externally\n> maintained system. It's not just software, it's a service (based on\n> software, obviously).\n>\n> --\n> Matthieu Moy\n> http://www-verimag.imag.fr/~moy/\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":"270820","messageId":"vpq4mie1m3n.fsf@grenoble-inp.fr","threadId":"40426","inReplyTo":"vpq7fnc83ki.fsf@grenoble-inp.fr","subject":"Re: [RFC/PATCH v1] Add Travis CI support","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2015-09-28T17:37:32Z","receivedAt":"2015-09-28T17:37:32Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Matthieu Moy writes:\n\n> * If the tests always pass, nobody ever get any email from Travis-CI.\n\nActually, I've just been reminded that the repository owner gets one\nemail per new ref (tag, branch) by default.\n\nDeactivating completely email notification is as simple as (in\n.travis.yml):\n\nnotifications:\n email: false\n\nand not getting emails when tests pass is done with\n\nnotifications:\n email:\n on_success: never\n\nIt probably makes sense to do the later in the case of Git, so that\nJunio doesn't get spammed when pushing topic branches to\nhttps://github.com/gitster/git.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"270830","messageId":"xmqqlhbqcrf7.fsf@gitster.mtv.corp.google.com","threadId":"40426","inReplyTo":"vpq4mie1m3n.fsf@grenoble-inp.fr","subject":"Re: [RFC/PATCH v1] Add Travis CI support","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-09-28T18:47:08Z","receivedAt":"2015-09-28T18:47:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> It probably makes sense to do the later in the case of Git, so that\n> Junio doesn't get spammed when pushing topic branches to\n> https://github.com/gitster/git.\n\nI won't enable it on github.com:gitster/git anyway, so I do not\nthink that is a concern. I thought what people are talking about\nwas to add it on github.com:git/git, but have I been misreading the\nthread? I do not even own the latter repository (I only can push\ninto it).\n"},{"id":"270833","messageId":"vpqfv1yz7kp.fsf@grenoble-inp.fr","threadId":"40426","inReplyTo":"xmqqlhbqcrf7.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC/PATCH v1] Add Travis CI support","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2015-09-28T19:07:18Z","receivedAt":"2015-09-28T19:07:18Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> Matthieu Moy writes:\n>\n>> It probably makes sense to do the later in the case of Git, so that\n>> Junio doesn't get spammed when pushing topic branches to\n>> https://github.com/gitster/git.\n>\n> I won't enable it on github.com:gitster/git anyway, so I do not\n> think that is a concern. I thought what people are talking about\n> was to add it on github.com:git/git, but have I been misreading the\n> thread? I do not even own the latter repository (I only can push\n> into it).\n\nYou're right: github.com:gitster/git shouldn't be affected. Builds are\ntriggered for branches outside github.com:git/git only when a\npull-requests to git/git is submitted.\n\nSo, you'd get a \"success\" email only when pushing a new tag (since the\nset of branches does not change).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"271012","messageId":"560EB36B.9020608@gmail.com","threadId":"40426","inReplyTo":"1443150875.3042.3.camel@kaarsemaker.net","subject":"Re: [RFC/PATCH v1] Add Travis CI support","fromName":"Sebastian Schuberth","fromEmail":"sschuberth@gmail.com","sentAt":"2015-10-02T16:40:11Z","receivedAt":"2015-10-02T16:40:11Z","isPatch":true,"sender":{"key":"sschuberth@gmail.com","avatar":"https://avatars.githubusercontent.com/u/349154?v=4"},"body":"On 25.09.2015 05:14, Dennis Kaarsemaker wrote:\n\n>>> My idea is that the owner of \"https://github.com/git/git\" enables this account\n>>> for Travis (it's free!). Then we would automatically get the test state for all\n>>> official branches.\n>>\n>> The last time I heard about this \"it's free\" thing, I thought I\n>> heard that it wants write access to the repository.\n>\n> It does not need write access to the git data, only to auxiliary GitHub\n> data: commit status and deployment status (where it can put \"this\n> commit failed tests\"), repository hooks (to set up build triggers),\n> team membership (ro) and email addresses (ro).\n\nAlso, as Roberto explained at [1], \"If you set up the webhook yourself, \nyou don't need to grant the [repository hooks] permissions\".\n\nBTW, there's already an attempt at creating a .travis.yml file at [2].\n\n[1] https://github.com/rtyley/submitgit/issues/16#issuecomment-120119634\n[2] https://github.com/git/git/pull/154\n\n-- \nSebastian Schuberth\n"},{"id":"271073","messageId":"CAFY1edZSNKepx_+2U=C-raOBiVK3Zh2r_Y_NO2-RtbhH_n-tdg@mail.gmail.com","threadId":"40426","inReplyTo":"xmqqlhbqcrf7.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC/PATCH v1] Add Travis CI support","fromName":"Roberto Tyley","fromEmail":"roberto.tyley@gmail.com","sentAt":"2015-10-03T22:23:52Z","receivedAt":"2015-10-03T22:23:52Z","isPatch":true,"sender":{"key":"roberto.tyley@gmail.com","avatar":"https://avatars.githubusercontent.com/u/52038?v=4"},"body":"On 28 September 2015 at 19:47, Junio C Hamano wrote:\n> I won't enable it on github.com:gitster/git anyway, so I do not\n> think that is a concern. I thought what people are talking about\n> was to add it on github.com:git/git, but have I been misreading the\n> thread? I do not even own the latter repository (I only can push\n> into it).\n\nI was momentarily surprised to hear that Junio doesn't own github.com/git/git\nbut I had a quick look at the github.com/git organisation, and it turns\nout that Peff and Scott Chacon are the current owners - so at the\nmoment I think they're the only ones who could switch on the GitHub\nwebhook to hit Travis.\n\nFor what it's worth, I'd love to see Travis CI - or any form of CI -\nrunning for the core Git project. It doesn't require giving write\naccess to Travis, and beyond the good reasons given by Lars,\nI'm also personally interested because it opens up the possibility\nof some useful enhancements to the submitGit flow - so that you\ncan't send email to the list without knowing you've broken tests\nfirst.\n\nRegarding Luke's concerns about excess emails coming from CI,\ndefault Travis behaviour is for emails to be sent to the committer and\nauthor, but only if they have write access to the repository the commit\nwas pushed to:\n\nhttp://docs.travis-ci.com/user/notifications/#How-is-the-build-email-receiver-determined%3F\n\nIf Travis emails do become problematic, you can disable them\ncompletely by adding 2 lines of config to the .travis.yml:\n\nhttp://docs.travis-ci.com/user/notifications/#Email-notifications\n\nGiven this, enabling Travis CI for git/git seems pretty low risk,\nare there any strong objections to it happening?\n"},{"id":"271074","messageId":"CAPc5daXkn=C-D5RQCw2w+JrHn7XZA6X-P4F-PugRe-S4Z2RO0g@mail.gmail.com","threadId":"40426","inReplyTo":"CAFY1edZSNKepx_+2U=C-raOBiVK3Zh2r_Y_NO2-RtbhH_n-tdg@mail.gmail.com","subject":"Re: [RFC/PATCH v1] Add Travis CI support","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-10-04T01:27:06Z","receivedAt":"2015-10-04T01:27:06Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"On Sat, Oct 3, 2015 at 3:23 PM, Roberto Tyley wrote:\n>\n> Given this, enabling Travis CI for git/git seems pretty low risk,\n> are there any strong objections to it happening?\n\nI still don't see a reason why git/git needs to be the one that is\nused, when somebody\nso interested (and I seem to see very many of them in the thread) can\nsacrifice his or\nher own fork and enable it him or herself.\n"},{"id":"271075","messageId":"xmqq612n2z3d.fsf@gitster.mtv.corp.google.com","threadId":"40426","inReplyTo":"CAPc5daXkn=C-D5RQCw2w+JrHn7XZA6X-P4F-PugRe-S4Z2RO0g@mail.gmail.com","subject":"Re: [RFC/PATCH v1] Add Travis CI support","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-10-04T01:37:26Z","receivedAt":"2015-10-04T01:37:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> On Sat, Oct 3, 2015 at 3:23 PM, Roberto Tyley wrote:\n>>\n>> Given this, enabling Travis CI for git/git seems pretty low risk,\n>> are there any strong objections to it happening?\n>\n> I still don't see a reason why git/git needs to be the one that is\n> used, when somebody\n> so interested (and I seem to see very many of them in the thread) can\n> sacrifice his or\n> her own fork and enable it him or herself.\n\nTo state it a bit differently.\n\nIf somebody says \"I've been maintaining a clone of git/git with\nTravis webhooks enabled and as the result caught this many glitches\nduring the past two months without any ill side effect. Here are\nthe patches to fix them, and by the way, the first patch in this\nseries is not a fix but the configuration to tell Travis how to run\ntests so that other people can enable it on _their_ own fork before\nthey send their own series to the mailing list.\" in the cover letter\nof a patch series, I would appreciate such a series greatly and\nwould not mind carrying one extra yml file in the tree at all.\n\nBut that is not what I am seeing in this thread at all. I am tired\nof hearing people telling others to help them by doing more without\ndoing the grunt work themselves.\n"},{"id":"271076","messageId":"20151004033423.GA20876@sigill.intra.peff.net","threadId":"40426","inReplyTo":"CAFY1edZSNKepx_+2U=C-raOBiVK3Zh2r_Y_NO2-RtbhH_n-tdg@mail.gmail.com","subject":"Re: [RFC/PATCH v1] Add Travis CI support","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-10-04T03:34:23Z","receivedAt":"2015-10-04T03:34:23Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Oct 03, 2015 at 11:23:52PM +0100, Roberto Tyley wrote:\n\n> On 28 September 2015 at 19:47, Junio C Hamano wrote:\n> > I won't enable it on github.com:gitster/git anyway, so I do not\n> > think that is a concern. I thought what people are talking about\n> > was to add it on github.com:git/git, but have I been misreading the\n> > thread? I do not even own the latter repository (I only can push\n> > into it).\n> \n> I was momentarily surprised to hear that Junio doesn't own github.com/git/git\n> but I had a quick look at the github.com/git organisation, and it turns\n> out that Peff and Scott Chacon are the current owners - so at the\n> moment I think they're the only ones who could switch on the GitHub\n> webhook to hit Travis.\n\nThere is a @git/git team on GitHub that should have full access to the\ngit/git repository, and Junio is on that (but I also do not _expect_\nJunio to spend time managing it; he has plenty of other things to do).\n\nI am on vacation at the moment, but am happy to look at it when I get\nback in a few weeks.\n\n-Peff\n"},{"id":"271081","messageId":"vpq1tdb83nt.fsf@grenoble-inp.fr","threadId":"40426","inReplyTo":"CAPc5daXkn=C-D5RQCw2w+JrHn7XZA6X-P4F-PugRe-S4Z2RO0g@mail.gmail.com","subject":"Re: [RFC/PATCH v1] Add Travis CI support","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2015-10-04T07:59:50Z","receivedAt":"2015-10-04T07:59:50Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> On Sat, Oct 3, 2015 at 3:23 PM, Roberto Tyley wrote:\n>>\n>> Given this, enabling Travis CI for git/git seems pretty low risk,\n>> are there any strong objections to it happening?\n>\n> I still don't see a reason why git/git needs to be the one that is\n> used,\n\nThe very nice thing with Travis-CI is that it does not only test the\nrepository's branches, but also all pull-requests. So, if it is\nactivated on git/git, it will become possible to have a flow like\n\n1) User pushes to his own repo, sends a pull-request,\n\n2) Travis-CI notices the pull-request and builds it (no action needed\n from anyone),\n\n3) Once the build is finished, the user can use e.g. SubmitGit to\n actually submit the code.\n\nThis has real benefits for the submitter (know if your code is broken\nearly), for the reviewers (things like \"you have a def-after-use\" would\nbe noticed by a computer before human beings start spending time on the\nreview), and for you (some issues noticed before a topic enters pu).\n\nThere's no extra work for the user at all compared to the standard\npull-request flow (nothing to do, just submit a PR), and a one-time\nsetup for the project.\n\nCurrenty, to mimick this flow, we would need something like\n\n1) User activates Travis-CI on his repo (each user would have to do\n this, not just once)\n\n2) User commits .travis.yml on top of the code to submit\n\n3) User pushes to his repo\n\n4) Travis-CI triggers a build\n\n5) User removes the commit introducing .travis.yml, force-pushes\n\n6) User submit the resulting code.\n\nThis is much more work for the user (read: nobody will do it, actually\nnobody do it currently) and less convenient for reviewers (who have no\nway to check whether the build passed).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"271083","messageId":"1443946429.3520.3.camel@kaarsemaker.net","threadId":"40426","inReplyTo":"xmqq612n2z3d.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC/PATCH v1] Add Travis CI support","fromName":"Dennis Kaarsemaker","fromEmail":"dennis@kaarsemaker.net","sentAt":"2015-10-04T08:13:49Z","receivedAt":"2015-10-04T08:13:49Z","isPatch":true,"sender":{"key":"dennis@kaarsemaker.net","avatar":"https://avatars.githubusercontent.com/u/200649?v=4"},"body":"On za, 2015-10-03 at 18:37 -0700, Junio C Hamano wrote:\n> If somebody says \"I've been maintaining a clone of git/git with\n> Travis webhooks enabled and as the result caught this many glitches\n> during the past two months without any ill side effect.\n\nI've been maintaining a clone of git/git with a different ci system\nenabled, and it hasn't really caught anything. Only the occasional test\nfailure in pu like the one I mailed about yesterday.\n\nThe automated testing of pull requests could be useful, but pull\nrequests don't seem to be used much yet.\n-- \nDennis Kaarsemaker\nwww.kaarsemaker.net\n"},{"id":"271084","messageId":"e8f26179dc4f590073efc8a2f1bf23d2@dscho.org","threadId":"40426","inReplyTo":"xmqq612n2z3d.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC/PATCH v1] Add Travis CI support","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2015-10-04T12:51:22Z","receivedAt":"2015-10-04T12:51:22Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn 2015-10-04 03:37, Junio C Hamano wrote:\n> Junio C Hamano writes:\n> \n>> On Sat, Oct 3, 2015 at 3:23 PM, Roberto Tyley wrote:\n>>>\n>>> Given this, enabling Travis CI for git/git seems pretty low risk,\n>>> are there any strong objections to it happening?\n>>\n>> I still don't see a reason why git/git needs to be the one that is\n>> used, when somebody\n>> so interested (and I seem to see very many of them in the thread) can\n>> sacrifice his or\n>> her own fork and enable it him or herself.\n> \n> To state it a bit differently.\n> \n> If somebody says \"I've been maintaining a clone of git/git with\n> Travis webhooks enabled and as the result caught this many glitches\n> during the past two months without any ill side effect.\n\nHeh... given that Travis CI requires that .travis.yml file, nobody can really say that they have been using Travis CI *before* you add that file to `master`. If you make successful testing with Travis a *precondition* before adding that file, it is kinda asking for the impossible.\n\nNow, I like Travis, even if I have used Jenkins previously (came as part of my previous day-job). And my experience with Jenkins (in the form of BuildHive) was pretty positive: it *did* catch a couple of breakages. Even with my Git fork.\n\nBut I agree with basically everybody who chimed in and said that the biggest bang for the buck would be made by enabling it on https://github.com/git/git.\n\nThe only cost I see is for that `.travis.yml` file to live in Git's source code. Small price to pay, if you ask me. If you do not want to use it yourself, that is fine. But I would like to ask for it to be included so that those of us who do want to benefit from Travis' testing are not precluded from doing so [*1*].\n\nAs far as I can tell, the patch is fine as-is. Although I would put the `before_script` commands into some file inside `contrib/`.\n\nThanks,\nDscho\n\nFootnote *1*: of course it would be possible to manually rebase the patch, or to set up a scripted version of that. That is very cumbersome, though, and the benefit would obviously be substantially diminished.\n"},{"id":"271091","messageId":"xmqqmvvy1q83.fsf@gitster.mtv.corp.google.com","threadId":"40426","inReplyTo":"vpq1tdb83nt.fsf@grenoble-inp.fr","subject":"Re: [RFC/PATCH v1] Add Travis CI support","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-10-04T17:46:36Z","receivedAt":"2015-10-04T17:46:36Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> Junio C Hamano writes:\n>>\n>> I still don't see a reason why git/git needs to be the one that is\n>> used,\n>\n> The very nice thing with Travis-CI is that it does not only test the\n> repository's branches, but also all pull-requests.\n\nOK, that is the first real argument I heard for enabling it on\ngit/git that is worth listening to.\n\nPractically, it has little value to run CI (whose only test is to\nrun \"make test\") on branches that I publish in that repository. By\nthe time a change hits that repository, \"make test\" has been run on\nmy end already, and the only thing the CI would catch is platform\ndependent glitches (e.g. Windows and Mac), dependency-related ones\n(e.g. p4), or breakages I already know about [*1*].\n\nBut we _do_ want to see tested patches submitted to the list so that\nreviewers do not have to waste time on obviously bogus patches\nreviewing (and the integrator wasting time on deconflicting). A\ntest that is PR-initiated would give us a real value there.\n\nThe repository that is used for the PR-initiated test does not have\nto be git/git (it only has to be a central well-known repository),\nbut similar to arrangement for SubmitGit, I agree that git/git would\nbe a good candidate for that \"central well-known\" one. There is not\nmuch point in introducing another \"if you want your topics tested,\nthrow a PR against this other repository\".\n\nSo,... I would not mind a patch that adds a CI configuration file (I\nwould really prefer it to be a battle-tested one, though) to my\ntree, and I would not mind if CI is enabled on git/git, if Peff or\nsomebody more security-minded than me thinks it is safe to do so.\n\nOne final question. Which configuration file does the CI use when\nrunning a PR-initiated test? The one already in the repository\ni.e. the target of the proposed pull, or the one that is possibly\nupdated by the PR?\n\nI am wondering if that can be an avenue for a possible mischief.\n\nThanks.\n\n\n[Footnote]\n\n*1* I occasionally do push out 'pu' with known breakages (e.g. the\nrecent 'lmdb' one) to make sure people are running the test suite so\nthat they will work with the topic author to resolve the issue\nwithout having to wait for me to tell the topic author about it;\nletting CI catch that kind of breakage would not add much value,\nbecause it is already known ;-)\n"},{"id":"271093","messageId":"xmqqio6m1pn2.fsf@gitster.mtv.corp.google.com","threadId":"40426","inReplyTo":"vpq1tdb83nt.fsf@grenoble-inp.fr","subject":"Re: [RFC/PATCH v1] Add Travis CI support","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-10-04T17:59:13Z","receivedAt":"2015-10-04T17:59:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> Currenty, to mimick this flow, we would need something like\n>\n> 1) User activates Travis-CI on his repo (each user would have to do\n> this, not just once)\n>\n> 2) User commits .travis.yml on top of the code to submit\n>\n> 3) User pushes to his repo\n>\n> 4) Travis-CI triggers a build\n>\n> 5) User removes the commit introducing .travis.yml, force-pushes\n>\n> 6) User submit the resulting code.\n\nI do not think it has to be so convoluted. I know this would appear\nto be more or less a moot point, as the long term direction would be\nto enable one on git/git and do PR-initiated tests, but I am writing\nit here because I would really prefer that the CI configuration file\nthat will be added to my tree is a \"battle tested\" one.\n\nA motivated user who wants to send a patch to add it to my tree can:\n\n (1) Fork from an ancient place, e.g. v2.0.0, and add the CI\n configuration file. Call that branch \"travis\".\n\n (2) Prepare topics that he wants to test (not related to \"add CI\n integration to Git\" topic) on its own topics, branching from my\n 'master' or 'maint' depending on the target track.\n\n (3) Keep a branch that merges (2) with (1). This could be a set of\n branches, one per topics in (2).\n\n (4) Have the CI monitor (3).\n\n (5) Make sure tests pass. Send (2) out via whatever means,\n e.g. via SubmitGit.\n\nAnd keep the set-up for a few months to make sure everything looks\ngood, before sending (1) out via SubmitGit.\n"},{"id":"271094","messageId":"1443981968.3520.5.camel@kaarsemaker.net","threadId":"40426","inReplyTo":"xmqqmvvy1q83.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC/PATCH v1] Add Travis CI support","fromName":"Dennis Kaarsemaker","fromEmail":"dennis@kaarsemaker.net","sentAt":"2015-10-04T18:06:08Z","receivedAt":"2015-10-04T18:06:08Z","isPatch":true,"sender":{"key":"dennis@kaarsemaker.net","avatar":"https://avatars.githubusercontent.com/u/200649?v=4"},"body":"On zo, 2015-10-04 at 10:46 -0700, Junio C Hamano wrote:\n> One final question. Which configuration file does the CI use when\n> running a PR-initiated test? The one already in the repository\n> i.e. the target of the proposed pull, or the one that is possibly\n> updated by the PR?\n>\n> I am wondering if that can be an avenue for a possible mischief.\n\nThe latter. And it can, as it can enable notifications.\n\n-- \nDennis Kaarsemaker\nwww.kaarsemaker.net\n"},{"id":"271122","messageId":"vpq4mi56c12.fsf@grenoble-inp.fr","threadId":"40426","inReplyTo":"1443981968.3520.5.camel@kaarsemaker.net","subject":"Re: [RFC/PATCH v1] Add Travis CI support","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2015-10-05T06:54:17Z","receivedAt":"2015-10-05T06:54:17Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Dennis Kaarsemaker writes:\n\n> On zo, 2015-10-04 at 10:46 -0700, Junio C Hamano wrote:\n>> One final question. Which configuration file does the CI use when\n>> running a PR-initiated test? The one already in the repository\n>> i.e. the target of the proposed pull, or the one that is possibly\n>> updated by the PR?\n>>\n>> I am wondering if that can be an avenue for a possible mischief.\n>\n> The latter. And it can, as it can enable notifications.\n\nOK, so an attacker can send emails (by faking one of the repository\nowner's identity on a commit, and then submitting a pull-request for\nthis commit). But such attacker could already send emails via GitHub to\nall repository watchers (not just owners) by sending pull-requests. Or\nby using his mailer.\n\nOther than that, Travis-CI uses a container-based infrastructure to\nensure clean and independent builds. So, an attacker could trigger a\nbuild doing \"rm -fr /\" or whatever without impacting other builds.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"271143","messageId":"xmqqpp0tz2ah.fsf@gitster.mtv.corp.google.com","threadId":"40426","inReplyTo":"1443981968.3520.5.camel@kaarsemaker.net","subject":"Re: [RFC/PATCH v1] Add Travis CI support","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-10-05T16:51:50Z","receivedAt":"2015-10-05T16:51:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Dennis Kaarsemaker writes:\n\n> On zo, 2015-10-04 at 10:46 -0700, Junio C Hamano wrote:\n>> One final question. Which configuration file does the CI use when\n>> running a PR-initiated test? The one already in the repository\n>> i.e. the target of the proposed pull, or the one that is possibly\n>> updated by the PR?\n>>\n>> I am wondering if that can be an avenue for a possible mischief.\n>\n> The latter. And it can, as it can enable notifications.\n\nSo it can add a slight annoyance if somebody wanted to, but not much\nover the annoyance a random pull-request can already give to project\nparticipants. IOW, nothing to worry about.\n\nThanks.\n"},{"id":"271438","messageId":"561B6959.20807@gmail.com","threadId":"40426","inReplyTo":"xmqqmvvy1q83.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC/PATCH v1] Add Travis CI support","fromName":"Sebastian Schuberth","fromEmail":"sschuberth@gmail.com","sentAt":"2015-10-12T08:03:37Z","receivedAt":"2015-10-12T08:03:37Z","isPatch":true,"sender":{"key":"sschuberth@gmail.com","avatar":"https://avatars.githubusercontent.com/u/349154?v=4"},"body":"On 10/4/2015 19:46, Junio C Hamano wrote:\n\n>> The very nice thing with Travis-CI is that it does not only test the\n>> repository's branches, but also all pull-requests.\n>\n> OK, that is the first real argument I heard for enabling it on\n> git/git that is worth listening to.\n\nI was mentioning that very argument in the context of PRs filed for use \nwith submitgit already back in July in the conversation at [1] in which \nyou took part.\n\n[1] https://github.com/rtyley/submitgit/issues/16\n\nRegards,\nSebastian\n"}]}