David Edmondson <dme at 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 at notmuchmail.org >> http://notmuchmail.org/mailman/listinfo/notmuch -------------- next part -------------- [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 at gmail.com | (650) 735-1773 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 180 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20140515/ae0d8c1b/attachment.pgp>