Re: [PATCH v3 1/3] Add Travis CI support

[Lars Schneider]

On 15 Oct 2015, at 10:12, Matthieu Moy  wrote:

> Lars Schneider  writes:
> 
>> I was reluctant to this because I feared problems. Especially while
>> running tests in parallel.
> 
> Isn't the point of using a CI tool to notice problems? ;-)
> 
> More seriously, running tests in parallel shouldn't be a problem since
> each test runs in its own directory with HOME set to this private
> directory, so two diffent tests should not interfer. If there's an issue
> with parallel tests, we probably prefer discovering them than avoiding
> them.
OK. Great!


>> make -j2 9min 11sec:
>> https://travis-ci.org/larsxschneider/git/jobs/85478022
>> 
>> make 17min 20sec:
>> https://travis-ci.org/larsxschneider/git/jobs/85432398
> 
> Since the tests are essentially IO-bound and not CPU-bound, it may even
> make sense to use -j3 here.
Hehe you're right.

make -j3 6min 2sec
https://travis-ci.org/larsxschneider/git/jobs/85497307

just for fun I tried a few more values and -j5 seems to be the best with 4min 
27sec
https://travis-ci.org/larsxschneider/git/jobs/85501015

-j6 is slower again. Do you see a reason not to use "-j5"?

Thanks,
Lars

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/3] Add Travis CI support

[Johannes Schindelin]

Hi,

On Thu, 15 Oct 2015, Matthieu Moy wrote:

> Lars Schneider  writes:
> 
> > I was reluctant to this because I feared problems. Especially while
> > running tests in parallel.
> 
> Isn't the point of using a CI tool to notice problems? ;-)
> 
> More seriously, running tests in parallel shouldn't be a problem since
> each test runs in its own directory with HOME set to this private
> directory, so two diffent tests should not interfer. If there's an issue
> with parallel tests, we probably prefer discovering them than avoiding
> them.

I vividly remember pulling my hair out over BuildHive (i.e. the Java-based
Jenkins alternative to Travis) failures that turned out to be
resource-related: I simply overloaded the BuildHive node.

So I assumed that the problems Lars referred to would not be problems of
Git, or the test suite, but of overwhelming a free service with an
unreasonable load.

> > make -j2 9min 11sec:
> > https://travis-ci.org/larsxschneider/git/jobs/85478022
> >
> > make 17min 20sec:
> > https://travis-ci.org/larsxschneider/git/jobs/85432398
> 
> Since the tests are essentially IO-bound and not CPU-bound, it may even
> make sense to use -j3 here.

I would like to caution against overloading Travis. They are really nice
to us, we should try to be nice to them, too.

Ciao,
Dscho
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/3] Add Travis CI support

[Jean-Noël Avila]

Le 15/10/2015 00:52, Lars Schneider a écrit :
> On 12 Oct 2015, at 22:20, Matthieu Moy  wrote:
>
>> larsxschnei...@gmail.com writes:
>>
>>> --- /dev/null
>>> +++ b/.travis.yml
>>> @@ -0,0 +1,46 @@
>>> +language: c
>>> +
>>> +os:
>>> +  - linux
>>> +  - osx
>>> +
>>> +compiler:
>>> +  - clang
>>> +  - gcc
>>> +
>>> +before_install:
>>> +  - >
>>> +export GIT_TEST_OPTS=" --quiet";
>>> +case "${TRAVIS_OS_NAME:-linux}" in
>>> +linux)
>>> +  wget -q https://package.perforce.com/perforce.pubkey -O - \
>>> +| sudo apt-key add -
>>> +  echo 'deb http://package.perforce.com/apt/ubuntu precise release' \
>>> +| sudo tee -a /etc/apt/sources.list
>>> +  wget -q https://packagecloud.io/gpg.key -O - | sudo apt-key add -
>>> +  echo 'deb https://packagecloud.io/github/git-lfs/debian/ jessie 
>>> main' \
>>> +| sudo tee -a /etc/apt/sources.list
>>> +  sudo apt-get update -qq
>>> +  sudo apt-get install -y apt-transport-https
>>> +  sudo apt-get install perforce-server git-lfs
>> Sorry if this has been discussed already, but do you really need these
>> "sudo" calls?
>>
>> They trigger builds on the legacy Travis CI infrastructure:
>>
>>  
>> http://docs.travis-ci.com/user/migrating-from-legacy/?utm_source=legacy-notice_medium=banner_campaign=legacy-upgrade
>>
>> No big deal, but getting rid of sudo would be cool, and documenting why
>> it can't easily be done in commit message and/or comments would be nice
>> otherwise.
> 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?
> 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...
> http://docs.travis-ci.com/user/migrating-from-legacy/?utm_source=legacy-notice_medium=banner_campaign=legacy-upgrade#Using-sudo-isn%E2%80%99t-possible-(right-now)
>
> - Lars


There's another hope. The requirements can be installed in the user's
HOME and cached between builds. In this case, no need for sudo.
Obviously, that rules out using apt and dpkg.

Jean-Noël
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/3] Add Travis CI support

[Matthieu Moy]

Lars Schneider  writes:

> 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 think this would deserve a mention in the commit message, but I won't
insist on that.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/3] Add Travis CI support

[Lars Schneider]

On 13 Oct 2015, at 12:32, Jean-Noël Avila  wrote:

> Le 11/10/2015 19:55, larsxschnei...@gmail.com a écrit :
>> +
>> +before_script: make
>> +
>> +script: make --quiet test
> 
> Travis can be used in container mode but that would need getting rid of
> "sudo" command and only installing from white-listed sources
> (https://github.com/travis-ci/apt-source-whitelist/blob/master/ubuntu.json)
> 
> Anyway, even within the present VM mode, 1.5 cores are available, so it
> makes sense to add "-j2" to every make commands.
> 
I was reluctant to this because I feared problems. Especially while running 
tests in parallel. However, the result looks quite good.

make -j2 9min 11sec:
https://travis-ci.org/larsxschneider/git/jobs/85478022

make 17min 20sec:
https://travis-ci.org/larsxschneider/git/jobs/85432398

If there is no argument against running test in parallel then I will add it to 
the next roll.

Thanks,
Lars--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/3] Add Travis CI support

[Matthieu Moy]

Lars Schneider  writes:

> I was reluctant to this because I feared problems. Especially while
> running tests in parallel.

Isn't the point of using a CI tool to notice problems? ;-)

More seriously, running tests in parallel shouldn't be a problem since
each test runs in its own directory with HOME set to this private
directory, so two diffent tests should not interfer. If there's an issue
with parallel tests, we probably prefer discovering them than avoiding
them.

> make -j2 9min 11sec:
> https://travis-ci.org/larsxschneider/git/jobs/85478022
>
> make 17min 20sec:
> https://travis-ci.org/larsxschneider/git/jobs/85432398

Since the tests are essentially IO-bound and not CPU-bound, it may even
make sense to use -j3 here.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/3] Add Travis CI support

[Matthieu Moy]

Johannes Schindelin  writes:

> On Thu, 15 Oct 2015, Matthieu Moy wrote:
>
>> Since the tests are essentially IO-bound and not CPU-bound, it may even
>> make sense to use -j3 here.
>
> I would like to caution against overloading Travis. They are really nice
> to us, we should try to be nice to them, too.

Right.

Using a bit of parallelism shouldn't harm (we put a heavier load on
them, but for a shorter time), so using -j2 or -j3 seems OK to me, but I
wouldn't go higher to remain gentle with Travis CI.

Note: I'm writting this without having a real idea of what consequence
of -jN have on their infrastructure, take my writing as wild guess, not
as real arguments.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/3] Add Travis CI support

[Lars Schneider]

On 12 Oct 2015, at 22:20, Matthieu Moy  wrote:

> larsxschnei...@gmail.com writes:
> 
>> --- /dev/null
>> +++ b/.travis.yml
>> @@ -0,0 +1,46 @@
>> +language: c
>> +
>> +os:
>> +  - linux
>> +  - osx
>> +
>> +compiler:
>> +  - clang
>> +  - gcc
>> +
>> +before_install:
>> +  - >
>> +export GIT_TEST_OPTS=" --quiet";
>> +case "${TRAVIS_OS_NAME:-linux}" in
>> +linux)
>> +  wget -q https://package.perforce.com/perforce.pubkey -O - \
>> +| sudo apt-key add -
>> +  echo 'deb http://package.perforce.com/apt/ubuntu precise release' \
>> +| sudo tee -a /etc/apt/sources.list
>> +  wget -q https://packagecloud.io/gpg.key -O - | sudo apt-key add -
>> +  echo 'deb https://packagecloud.io/github/git-lfs/debian/ jessie main' 
>> \
>> +| sudo tee -a /etc/apt/sources.list
>> +  sudo apt-get update -qq
>> +  sudo apt-get install -y apt-transport-https
>> +  sudo apt-get install perforce-server git-lfs
> 
> Sorry if this has been discussed already, but do you really need these
> "sudo" calls?
> 
> They trigger builds on the legacy Travis CI infrastructure:
> 
>  
> http://docs.travis-ci.com/user/migrating-from-legacy/?utm_source=legacy-notice_medium=banner_campaign=legacy-upgrade
> 
> No big deal, but getting rid of sudo would be cool, and documenting why
> it can't easily be done in commit message and/or comments would be nice
> otherwise.
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?
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...
http://docs.travis-ci.com/user/migrating-from-legacy/?utm_source=legacy-notice_medium=banner_campaign=legacy-upgrade#Using-sudo-isn%E2%80%99t-possible-(right-now)

- Lars--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/3] Add Travis CI support

[Jean-Noël Avila]

Le 11/10/2015 19:55, larsxschnei...@gmail.com a écrit :
> +
> +before_script: make
> +
> +script: make --quiet test

Travis can be used in container mode but that would need getting rid of
"sudo" command and only installing from white-listed sources
(https://github.com/travis-ci/apt-source-whitelist/blob/master/ubuntu.json)

Anyway, even within the present VM mode, 1.5 cores are available, so it
makes sense to add "-j2" to every make commands.

 

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/3] Add Travis CI support

[Sebastian Schuberth]

On 10/11/2015 19:55, larsxschnei...@gmail.com wrote:


+  sudo apt-get update -qq
+  sudo apt-get install -y apt-transport-https
+  sudo apt-get install perforce-server git-lfs


Why no "-y" also in this line, or append these to the previous line?

Or maybe even better, like [1] does, also use "--qq" (which implies 
"-y") for "apt-get install"?



+install: make configure && ./configure
+
+before_script: make
+
+script: make --quiet test


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:


before_script: make configure && ./configure

script: make --quiet test

[1] https://github.com/git/git/pull/154/files

Regards,
Sebastian


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/3] Add Travis CI support

[Junio C Hamano]

Sebastian Schuberth  writes:

> 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:
>
> before_script: make configure && ./configure
>
> script: make --quiet test

Very good point.  Do we even need to do anything in the "install"
target?  We aim to be able to testable without any installed Git,
and not running "make install" at all, ever, would be one way to
make sure that works.

This is a slightly related tangent, but we saw a few build issues
reported recently on customized configurations like NO_PTHREAD.  If
we are to start using automated tests, I wonder if we want to build
(and optionally test) with various combinations of the customization
options (e.g. NO_CURL, NO_OPENSSL, NO_MMAP, NO_IPV6, NO_PERL etc.)

Thanks.


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/3] Add Travis CI support

[Lars Schneider]

>> +  brew_force_set_latest_binary_hash () {
>> +FORUMULA=$1
> 
> Is this spelling intentional or is it a misspelling of "formula"?

This is a misspelling. I will fix it.

Thanks,
Lars
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/3] Add Travis CI support

[Lars Schneider]

On 12 Oct 2015, at 01:05, Sebastian Schuberth  wrote:

> On 10/11/2015 19:55, larsxschnei...@gmail.com wrote:
> 
>> +  sudo apt-get update -qq
>> +  sudo apt-get install -y apt-transport-https
>> +  sudo apt-get install perforce-server git-lfs
> 
> Why no "-y" also in this line, or append these to the previous line?
> 
> Or maybe even better, like [1] does, also use "--qq" (which implies "-y") for 
> "apt-get install"?
Agreed!

> 
>> +install: make configure && ./configure
>> +
>> +before_script: make
>> +
>> +script: make --quiet test
> 
> 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:
> 
> before_script: make configure && ./configure
> 
> script: make --quiet test

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.

Do you see value in "make" logs? 

If yes then we could also do:
before_script: make configure && ./configure && make

If no then I will take your suggestion.

Thanks,
Lars--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/3] Add Travis CI support

[Sebastian Schuberth]

On Mon, Oct 12, 2015 at 6:02 PM, Junio C Hamano  wrote:

>> 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:
>>
>> before_script: make configure && ./configure
>>
>> script: make --quiet test
>
> Very good point.  Do we even need to do anything in the "install"
> target?  We aim to be able to testable without any installed Git,
> and not running "make install" at all, ever, would be one way to
> make sure that works.

Note that Travis' "install" step is about installing dependencies for
the application to build [1], not for installing the built application
(i.e. what "make install" does). In any case, I still think
configuring the application to built in this step is wrong.

> we are to start using automated tests, I wonder if we want to build
> (and optionally test) with various combinations of the customization
> options (e.g. NO_CURL, NO_OPENSSL, NO_MMAP, NO_IPV6, NO_PERL etc.)

I like that idea, but I think we should save that for a future
improvement to .travis.yml.

[1] http://docs.travis-ci.com/user/installing-dependencies/

-- 
Sebastian Schuberth
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/3] Add Travis CI support

[Lars Schneider]

On 12 Oct 2015, at 12:37, Sebastian Schuberth  wrote:

> On Mon, Oct 12, 2015 at 7:12 PM, Lars Schneider
>  wrote:
> 
 +install: make configure && ./configure
 +
 +before_script: make
 +
 +script: make --quiet test
>>> 
>>> 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:
>>> 
>>> before_script: make configure && ./configure
>>> 
>>> script: make --quiet test
>> 
>> 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.
> 
> To make this more clear, I guess what you're referring to is the
> visual difference between [1] and [2], correct?
correct!

> 
>> Do you see value in "make" logs?
>> 
>> If yes then we could also do:
>> before_script: make configure && ./configure && make
> 
> Reading through Travis' docs [3] again, "before_script" is documented
> to "return a non-zero exit code, the build is errored and stops
> immediately", while "script" is documented as "returns a non-zero exit
> code, the build is failed, but continues to run before being marked as
> failed". As it does not make much sense to continue the build or even
> start testing if the build failed, maybe it's indeed best to do:
> 
> before_script: make configure && ./configure && make
> 
> script: make --quiet test

Ok, then I will make it so :-)

Thanks,
Lars--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/3] Add Travis CI support

[Sebastian Schuberth]

On Mon, Oct 12, 2015 at 9:43 PM, Lars Schneider
 wrote:

>> Reading through Travis' docs [3] again, "before_script" is documented
>> to "return a non-zero exit code, the build is errored and stops
>> immediately", while "script" is documented as "returns a non-zero exit
>> code, the build is failed, but continues to run before being marked as
>> failed". As it does not make much sense to continue the build or even
>> start testing if the build failed, maybe it's indeed best to do:
>>
>> before_script: make configure && ./configure && make
>>
>> script: make --quiet test
>
> Ok, then I will make it so :-)

Also, this has the added benefit of being quickly able to see how much
time building vs testing took. As these two are the big blocks, we'd
want to optimize both steps for time, and it's easier to see what we
gain e.g. from a possible build-time improvement if these steps are
listed individually in the Travis log.

-- 
Sebastian Schuberth
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/3] Add Travis CI support

[Matthieu Moy]

larsxschnei...@gmail.com writes:

> --- /dev/null
> +++ b/.travis.yml
> @@ -0,0 +1,46 @@
> +language: c
> +
> +os:
> +  - linux
> +  - osx
> +
> +compiler:
> +  - clang
> +  - gcc
> +
> +before_install:
> +  - >
> +export GIT_TEST_OPTS=" --quiet";
> +case "${TRAVIS_OS_NAME:-linux}" in
> +linux)
> +  wget -q https://package.perforce.com/perforce.pubkey -O - \
> +| sudo apt-key add -
> +  echo 'deb http://package.perforce.com/apt/ubuntu precise release' \
> +| sudo tee -a /etc/apt/sources.list
> +  wget -q https://packagecloud.io/gpg.key -O - | sudo apt-key add -
> +  echo 'deb https://packagecloud.io/github/git-lfs/debian/ jessie main' \
> +| sudo tee -a /etc/apt/sources.list
> +  sudo apt-get update -qq
> +  sudo apt-get install -y apt-transport-https
> +  sudo apt-get install perforce-server git-lfs

Sorry if this has been discussed already, but do you really need these
"sudo" calls?

They trigger builds on the legacy Travis CI infrastructure:

  
http://docs.travis-ci.com/user/migrating-from-legacy/?utm_source=legacy-notice_medium=banner_campaign=legacy-upgrade

No big deal, but getting rid of sudo would be cool, and documenting why
it can't easily be done in commit message and/or comments would be nice
otherwise.

Thanks for working on that!

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/3] Add Travis CI support

[Sebastian Schuberth]

On Mon, Oct 12, 2015 at 7:12 PM, Lars Schneider
 wrote:

>>> +install: make configure && ./configure
>>> +
>>> +before_script: make
>>> +
>>> +script: make --quiet test
>>
>> 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:
>>
>> before_script: make configure && ./configure
>>
>> script: make --quiet test
>
> 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.

To make this more clear, I guess what you're referring to is the
visual difference between [1] and [2], correct?

> Do you see value in "make" logs?
>
> If yes then we could also do:
> before_script: make configure && ./configure && make

Reading through Travis' docs [3] again, "before_script" is documented
to "return a non-zero exit code, the build is errored and stops
immediately", while "script" is documented as "returns a non-zero exit
code, the build is failed, but continues to run before being marked as
failed". As it does not make much sense to continue the build or even
start testing if the build failed, maybe it's indeed best to do:

before_script: make configure && ./configure && make

script: make --quiet test

[1] https://travis-ci.org/larsxschneider/git/jobs/84805733
[2] https://travis-ci.org/larsxschneider/git/jobs/84955658
[3] http://docs.travis-ci.com/user/customizing-the-build/

-- 
Sebastian Schuberth
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/3] Add Travis CI support

[Lars Schneider]

On 12 Oct 2015, at 09:02, Junio C Hamano  wrote:

> Sebastian Schuberth  writes:
> 
>> 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:
>> 
>> before_script: make configure && ./configure
>> 
>> script: make --quiet test
> 
> Very good point.  Do we even need to do anything in the "install"
> target?  We aim to be able to testable without any installed Git,
> and not running "make install" at all, ever, would be one way to
> make sure that works.
The 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.


> This is a slightly related tangent, but we saw a few build issues
> reported recently on customized configurations like NO_PTHREAD.  If
> we are to start using automated tests, I wonder if we want to build
> (and optionally test) with various combinations of the customization
> options (e.g. NO_CURL, NO_OPENSSL, NO_MMAP, NO_IPV6, NO_PERL etc.)
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:
{Linux | OSX} * {gcc | clang} * {Default, NO_PTHREAD, NO_CURL, NO_OPENSSL, 
NO_MMAP, NO_IPV6, NO_PERL}

These result in 28 (= 2*2*7) combinations. I created a build without the 
"Default" environment (=24 combination) here:
https://travis-ci.org/larsxschneider/git/builds/84978673

Should I add them them to the Travis CI patch?

Thanks,
Lars

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/3] Add Travis CI support

[Matthieu Moy]

Lars Schneider  writes:

> {Linux | OSX} * {gcc | clang} * {Default, NO_PTHREAD, NO_CURL, NO_OPENSSL, 
> NO_MMAP, NO_IPV6, NO_PERL}

Another option would be to have a single "NO_*" build, that would
activate all NO_PTHREAD, NO_CURL, NO_OPENSSL, NO_MMAP, NO_IPV6, NO_PERL
at the same time. We'd miss issues with perl but no pthread or so, but
this should catch most issues.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 1/3] Add Travis CI support

[larsxschneider]

From: Lars Schneider 

The tests are currently executed on "Ubuntu 12.04 LTS Server Edition
64 bit" and on "OS X Mavericks" using gcc and clang.

Perforce and Git-LFS are installed and therefore available for the
respective tests.

Signed-off-by: Lars Schneider 
---
 .travis.yml | 46 ++
 1 file changed, 46 insertions(+)
 create mode 100644 .travis.yml

diff --git a/.travis.yml b/.travis.yml
new file mode 100644
index 000..25a7079
--- /dev/null
+++ b/.travis.yml
@@ -0,0 +1,46 @@
+language: c
+
+os:
+  - linux
+  - osx
+
+compiler:
+  - clang
+  - gcc
+
+before_install:
+  - >
+export GIT_TEST_OPTS=" --quiet";
+case "${TRAVIS_OS_NAME:-linux}" in
+linux)
+  wget -q https://package.perforce.com/perforce.pubkey -O - \
+| sudo apt-key add -
+  echo 'deb http://package.perforce.com/apt/ubuntu precise release' \
+| sudo tee -a /etc/apt/sources.list
+  wget -q https://packagecloud.io/gpg.key -O - | sudo apt-key add -
+  echo 'deb https://packagecloud.io/github/git-lfs/debian/ jessie main' \
+| sudo tee -a /etc/apt/sources.list
+  sudo apt-get update -qq
+  sudo apt-get install -y apt-transport-https
+  sudo apt-get install perforce-server git-lfs
+  ;;
+osx)
+  brew_force_set_latest_binary_hash () {
+FORUMULA=$1
+SHA=$(brew fetch --force $FORUMULA 2>&1 | grep ^SHA256: | cut -d ' ' 
-f 2)
+sed -E -i.bak "s/sha256 \"[0-9a-f]{64}\"/sha256 \"$SHA\"/g" \
+  /usr/local/Library/Taps/homebrew/homebrew-binary/$FORUMULA.rb
+  }
+  brew update
+  brew tap homebrew/binary
+  brew_force_set_latest_binary_hash perforce
+  brew_force_set_latest_binary_hash perforce-server
+  brew install git-lfs perforce-server perforce
+  ;;
+esac
+
+install: make configure && ./configure
+
+before_script: make
+
+script: make --quiet test
-- 
2.5.1

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/3] Add Travis CI support

[Eric Sunshine]

On Sun, Oct 11, 2015 at 1:55 PM,   wrote:
> From: Lars Schneider 
>
> The tests are currently executed on "Ubuntu 12.04 LTS Server Edition
> 64 bit" and on "OS X Mavericks" using gcc and clang.
>
> Perforce and Git-LFS are installed and therefore available for the
> respective tests.
>
> Signed-off-by: Lars Schneider 
> ---
> diff --git a/.travis.yml b/.travis.yml
> new file mode 100644
> index 000..25a7079
> --- /dev/null
> +++ b/.travis.yml
> @@ -0,0 +1,46 @@
> +language: c
> +
> +os:
> +  - linux
> +  - osx
> +
> +compiler:
> +  - clang
> +  - gcc
> +
> +before_install:
> +  - >
> +export GIT_TEST_OPTS=" --quiet";
> +case "${TRAVIS_OS_NAME:-linux}" in
> +linux)
> +  wget -q https://package.perforce.com/perforce.pubkey -O - \
> +| sudo apt-key add -
> +  echo 'deb http://package.perforce.com/apt/ubuntu precise release' \
> +| sudo tee -a /etc/apt/sources.list
> +  wget -q https://packagecloud.io/gpg.key -O - | sudo apt-key add -
> +  echo 'deb https://packagecloud.io/github/git-lfs/debian/ jessie main' \
> +| sudo tee -a /etc/apt/sources.list
> +  sudo apt-get update -qq
> +  sudo apt-get install -y apt-transport-https
> +  sudo apt-get install perforce-server git-lfs
> +  ;;
> +osx)
> +  brew_force_set_latest_binary_hash () {
> +FORUMULA=$1

Is this spelling intentional or is it a misspelling of "formula"?

> +SHA=$(brew fetch --force $FORUMULA 2>&1 | grep ^SHA256: | cut -d ' ' 
> -f 2)
> +sed -E -i.bak "s/sha256 \"[0-9a-f]{64}\"/sha256 \"$SHA\"/g" \
> +  /usr/local/Library/Taps/homebrew/homebrew-binary/$FORUMULA.rb
> +  }
> +  brew update
> +  brew tap homebrew/binary
> +  brew_force_set_latest_binary_hash perforce
> +  brew_force_set_latest_binary_hash perforce-server
> +  brew install git-lfs perforce-server perforce
> +  ;;
> +esac
> +
> +install: make configure && ./configure
> +
> +before_script: make
> +
> +script: make --quiet test
> --
> 2.5.1
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html