[PATCH v2] Enable Travis-CI as a backup continuous integration

[PATCH v2] Enable Travis-CI as a backup continuous integration

[Wael M. Nasreddine]

The v2 adds a notification section to send failure (or back to passing)
notifications to #notmuch on Freenode.

[PATCH v2] Enable Travis-CI as a backup continuous integration service.

[Wael M. Nasreddine]

You can access the dashboard at https://travis-ci.org/notmuch/notmuch
---
 .travis.yml | 12 ++++++++++++
 1 file changed, 12 insertions(+)
 create mode 100644 .travis.yml

diff --git a/.travis.yml b/.travis.yml
new file mode 100644
index 0000000..e8c3011
--- /dev/null
+++ b/.travis.yml
@@ -0,0 +1,12 @@
+language: c
+before_install:
+  - sudo apt-get update -qq
+  - wget 'https://launchpad.net/ubuntu/+archive/primary/+files/zlib1g-dev_1.2.8.dfsg-1ubuntu1_amd64.deb'
+  - wget 'https://launchpad.net/ubuntu/+archive/primary/+files/zlib1g_1.2.8.dfsg-1ubuntu1_amd64.deb'
+  - sudo dpkg -i zlib1g-dev_1.2.8.dfsg-1ubuntu1_amd64.deb zlib1g_1.2.8.dfsg-1ubuntu1_amd64.deb
+  - sudo apt-get install -f
+  - sudo apt-get install dtach libxapian-dev libgmime-2.6-dev libtalloc-dev python-sphinx
+
+script: make test
+notifications:
+  irc: "chat.freenode.net#notmuch"
-- 
1.9.1.423.g4596e3a

Re: [PATCH v2] Enable Travis-CI as a backup continuous integration service.

[David Edmondson]

[-- Attachment #1: Type: text/plain, Size: 2101 bytes --]

On Wed, May 14 2014, Wael M. Nasreddine wrote:
> You can access the dashboard at https://travis-ci.org/notmuch/notmuch
> ---
>  .travis.yml | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
>  create mode 100644 .travis.yml
>
> diff --git a/.travis.yml b/.travis.yml
> new file mode 100644
> index 0000000..e8c3011
> --- /dev/null
> +++ b/.travis.yml
> @@ -0,0 +1,12 @@
> +language: c
> +before_install:
> +  - sudo apt-get update -qq
> +  - wget 'https://launchpad.net/ubuntu/+archive/primary/+files/zlib1g-dev_1.2.8.dfsg-1ubuntu1_amd64.deb'
> +  - wget 'https://launchpad.net/ubuntu/+archive/primary/+files/zlib1g_1.2.8.dfsg-1ubuntu1_amd64.deb'
> +  - sudo dpkg -i zlib1g-dev_1.2.8.dfsg-1ubuntu1_amd64.deb
>      zlib1g_1.2.8.dfsg-1ubuntu1_amd64.deb

Wael, I don't know much at all about travis (I gather that it's some
sort of continuous integration test tool), but grabbing very specific
zlib packages from a place on the 'net and then installing them seems
fragile.

- What happens when those are no longer the right version numbers?
- What happens when those versions are already provided by the standard
  repository?
- What happens when newer versions are provided by the standard
  repository?
- What happens if travis runs start happening on (say) an arm64 machine?

I realise that you might answer "I will keep this up to date", but we
have to worry about what happens if you lose interest and wander away.

What is required to get the updated (as I presume that is what they are)
versions of zlib into the normal package repositories? Is it possible to
specify that travis should use the equivalent of Debian testing or
experimental repositories?

> +  - sudo apt-get install -f
> +  - sudo apt-get install dtach libxapian-dev libgmime-2.6-dev libtalloc-dev python-sphinx
> +
> +script: make test
> +notifications:
> +  irc: "chat.freenode.net#notmuch"
> -- 
> 1.9.1.423.g4596e3a
>
> _______________________________________________
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 310 bytes --]

Re: [PATCH v2] Enable Travis-CI as a backup continuous integration service.

[Wael Nasreddine]

[-- Attachment #1: Type: text/plain, Size: 3435 bytes --]

David Edmondson <dme@dme.org> writes:

> On Wed, May 14 2014, Wael M. Nasreddine wrote:
>> You can access the dashboard at https://travis-ci.org/notmuch/notmuch
>> ---
>>  .travis.yml | 12 ++++++++++++
>>  1 file changed, 12 insertions(+)
>>  create mode 100644 .travis.yml
>>
>> diff --git a/.travis.yml b/.travis.yml
>> new file mode 100644
>> index 0000000..e8c3011
>> --- /dev/null
>> +++ b/.travis.yml
>> @@ -0,0 +1,12 @@
>> +language: c
>> +before_install:
>> +  - sudo apt-get update -qq
>> +  - wget 'https://launchpad.net/ubuntu/+archive/primary/+files/zlib1g-dev_1.2.8.dfsg-1ubuntu1_amd64.deb'
>> +  - wget 'https://launchpad.net/ubuntu/+archive/primary/+files/zlib1g_1.2.8.dfsg-1ubuntu1_amd64.deb'
>> +  - sudo dpkg -i zlib1g-dev_1.2.8.dfsg-1ubuntu1_amd64.deb
>>      zlib1g_1.2.8.dfsg-1ubuntu1_amd64.deb
>
> Wael, I don't know much at all about travis (I gather that it's some
> sort of continuous integration test tool), but grabbing very specific
> zlib packages from a place on the 'net and then installing them seems
> fragile.
>

It is fragile, but unfortunately there's no way (As far as I know)
around this problem. Travis-CI is currently running Ubuntu Precise
(12.04) and they have plans to update to Trusty[0] but it's going to take
them some time.

> - What happens when those are no longer the right version numbers?
I can host the files in a Github repository if that would work better? I
am not very concerned about security in this case because Travis runs in
an isolated disposable VM created for the build and destroyed afterwards.

> - What happens when those versions are already provided by the standard
>   repository?

When #2046[0] is fixed by the Travis-CI team, our travis.yml will be
updated to work accordingly.

> - What happens when newer versions are provided by the standard
>   repository?

Same as above. Once they run trusty, this hack will go away.

> - What happens if travis runs start happening on (say) an arm64 machine?
>

Travis is currently running amd64[1] and I don't think they have plans
to change that, in fact I heard that they have plans to support more
architectures configurable in .travis.yml

> I realise that you might answer "I will keep this up to date", but we
> have to worry about what happens if you lose interest and wander away.
>

Absolutely, I understand your point and no one can guarantee
maintainer-ship. I can modify my patch and add documentation (comments
in the yaml file) about what each flag does, where can you documentation
about it and of course details about the hack. Would that be helpful?

> What is required to get the updated (as I presume that is what they are)
> versions of zlib into the normal package repositories? Is it possible to
> specify that travis should use the equivalent of Debian testing or
> experimental repositories?

Your build runs in a disposable VM, we have root access so we can do
about anything on the box, however you should keep in mind that they
kill builds after certain amount of time (considered as timeout)[2]

>
>> +  - sudo apt-get install -f
>> +  - sudo apt-get install dtach libxapian-dev libgmime-2.6-dev libtalloc-dev python-sphinx
>> +
>> +script: make test
>> +notifications:
>> +  irc: "chat.freenode.net#notmuch"
>> --
>> 1.9.1.423.g4596e3a
>>
>> _______________________________________________
>> notmuch mailing list
>> notmuch@notmuchmail.org
>> http://notmuchmail.org/mailman/listinfo/notmuch

[-- Attachment #2.1: Type: text/plain, Size: 283 bytes --]


[0]: https://github.com/travis-ci/travis-ci/issues/2046
[1]: http://docs.travis-ci.com/user/ci-environment/#CI-environment-OS
[2]: http://docs.travis-ci.com/user/build-configuration/#sts=Build Timeouts
--
Wael Nasreddine | SRE at Google | wael.nasreddine@gmail.com | (650) 735-1773

[-- Attachment #2.2: Type: application/pgp-signature, Size: 180 bytes --]

Re: [PATCH v2] Enable Travis-CI as a backup continuous integration service.

[W. Trevor King]

[-- Attachment #1: Type: text/plain, Size: 1126 bytes --]

On Thu, May 15, 2014 at 10:40:06AM -0700, Wael Nasreddine wrote:
> David Edmondson writes:
> > I realise that you might answer "I will keep this up to date", but
> > we have to worry about what happens if you lose interest and
> > wander away.
> 
> Absolutely, I understand your point and no one can guarantee
> maintainer-ship. I can modify my patch and add documentation
> (comments in the yaml file) about what each flag does, where can you
> documentation about it and of course details about the hack. Would
> that be helpful?

I personally love comments like this, but I prefer them in the commit
message.  Otherwise the source becomes one humongous comment with a
bit of interspersed code ;).  An interactive blame (like you get with
tig [1] and probably any interactive Git frontent) makes these
commit-messages easily accessible (assuming they're not buried under
whitespace churn, etc.)

Cheers,
Trevor

[1]: http://jonas.nitro.dk/tig/

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH v2] Enable Travis-CI as a backup continuous integration service.

[Wael Nasreddine]

[-- Attachment #1: Type: text/plain, Size: 1243 bytes --]

"W. Trevor King" <wking@tremily.us> writes:

> On Thu, May 15, 2014 at 10:40:06AM -0700, Wael Nasreddine wrote:
>> David Edmondson writes:
>> > I realise that you might answer "I will keep this up to date", but
>> > we have to worry about what happens if you lose interest and
>> > wander away.
>> 
>> Absolutely, I understand your point and no one can guarantee
>> maintainer-ship. I can modify my patch and add documentation
>> (comments in the yaml file) about what each flag does, where can you
>> documentation about it and of course details about the hack. Would
>> that be helpful?
>
> I personally love comments like this, but I prefer them in the commit
> message.  Otherwise the source becomes one humongous comment with a
> bit of interspersed code ;).  An interactive blame (like you get with
> tig [1] and probably any interactive Git frontent) makes these
> commit-messages easily accessible (assuming they're not buried under
> whitespace churn, etc.)
>

@Dan what do you think? File comments or commit message?

> Cheers,
> Trevor
>
> [1]: http://jonas.nitro.dk/tig/
>
> -- 
> This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
> For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2.1: Type: text/plain, Size: 83 bytes --]

-- 
Wael Nasreddine | SRE at Google | wael.nasreddine@gmail.com | (650) 735-1773

[-- Attachment #2.2: Type: application/pgp-signature, Size: 180 bytes --]

Re: [PATCH v2] Enable Travis-CI as a backup continuous integration service.

[David Edmondson]

[-- Attachment #1: Type: text/plain, Size: 2278 bytes --]

On Thu, May 15 2014, Wael Nasreddine wrote:
> It is fragile, but unfortunately there's no way (As far as I know)
> around this problem. Travis-CI is currently running Ubuntu Precise
> (12.04) and they have plans to update to Trusty[0] but it's going to take
> them some time.

Please forgive my ignorance. What is the place from which you are
grabbing these packages? It doesn't seem to be part of the Ubuntu
repositories. Is there no backports or security-updates repository for
Ubuntu 12.04?

I'm really asking whether there is a way to use the standard Ubuntu
repositories to get the packages rather than downloading them directly.

>> - What happens when those are no longer the right version numbers?
> I can host the files in a Github repository if that would work better? I
> am not very concerned about security in this case because Travis runs in
> an isolated disposable VM created for the build and destroyed
> afterwards.

I have no strong preference. If they aren't coming from the standard
repositories then it's all just slightly different versions of bad :-)

>> - What happens when those versions are already provided by the standard
>>   repository?
>
> When #2046[0] is fixed by the Travis-CI team, our travis.yml will be
> updated to work accordingly.

Presume that you have lost interest in notmuch. How will we know that
this has happened?

>> - What happens if travis runs start happening on (say) an arm64 machine?
>
> Travis is currently running amd64[1] and I don't think they have plans
> to change that, in fact I heard that they have plans to support more
> architectures configurable in .travis.yml

Your two statements seem contradictory here.

>> I realise that you might answer "I will keep this up to date", but we
>> have to worry about what happens if you lose interest and wander away.
>
> Absolutely, I understand your point and no one can guarantee
> maintainer-ship. I can modify my patch and add documentation (comments
> in the yaml file) about what each flag does, where can you documentation
> about it and of course details about the hack. Would that be helpful?

Comments explaining the need to grab the packages directly would be the
absolute minimum requirement, I think. Include a pointer to the travis
issue that you mentioned.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 310 bytes --]

Re: [PATCH v2] Enable Travis-CI as a backup continuous integration service.

[David Edmondson]

[-- Attachment #1: Type: text/plain, Size: 1201 bytes --]

On Thu, May 15 2014, W. Trevor King wrote:
> On Thu, May 15, 2014 at 10:40:06AM -0700, Wael Nasreddine wrote:
>> David Edmondson writes:
>> > I realise that you might answer "I will keep this up to date", but
>> > we have to worry about what happens if you lose interest and
>> > wander away.
>> 
>> Absolutely, I understand your point and no one can guarantee
>> maintainer-ship. I can modify my patch and add documentation
>> (comments in the yaml file) about what each flag does, where can you
>> documentation about it and of course details about the hack. Would
>> that be helpful?
>
> I personally love comments like this, but I prefer them in the commit
> message.  Otherwise the source becomes one humongous comment with a
> bit of interspersed code ;).  An interactive blame (like you get with
> tig [1] and probably any interactive Git frontent) makes these
> commit-messages easily accessible (assuming they're not buried under
> whitespace churn, etc.)

I disagree. In this case, the comments explain the code, so they belong
in the code.

When the version number of zlib we have to download changes, that's the
type of comment that belongs in the commit message.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 310 bytes --]